/ext CGIs cannot set cookies. Feature or bug?
(1) By Stephan Beal (stephan) on 2020-12-12 08:07:16 [source]
To my great dismay, i just learned that CGIs running from /ext cannot set cookies. The CGI i was hoping to host via /ext, rather than setting up Apache for it, needs to be able to set an app-level login cookie unrelated to the fossil login, so this behaviour kills that idea.
Is this a feature, a bug, or a technical hurdle which simply hasn't been yet overcome (maybe in the passing-on of a white-list of response headers which won't interfere with fossil's own)? If one of the latter two, i'll take a look at resolving it.
:-?
(2) By Chris (crustyoz) on 2020-12-12 12:03:49 in reply to 1 [link] [source]
Not answering your question but suggesting an alternative. Can you use localstorage in the browser to the same effect? I use it instead of passing cookies. Javascript is needed in the browser to handle either form of storage. Session creation and expiry is done on the server so no difference there.
(3) By Stephan Beal (stephan) on 2020-12-12 13:28:36 in reply to 2 [link] [source]
Not answering your question but suggesting an alternative. Can you use localstorage in the browser to the same effect?
That "would work" but would require that i structure all requests to pass around their authentication token (which is normally passed around as a cookie) with each request. Neither a huge deal nor major effort, but...
It turns out that i can work (==have worked) around it for this case...
For this particular use case i only need 2 levels of access - guest and admin - and there will only be one admin (me, (surprise, surprise)). Ergo... it turns out that i can piggyback on fossil's own login capabilities for this purpose, by simply logging in to the fossil repo before accessing the /ext-driven bits, and from the CGI i can check the FOSSIL_USER and/or FOSSIL_CAPABILITIES environment variables. Should i ever want/need a non-admin user level, i can get by with hijacking an otherwise-unused permission like ticket-write for such users and give them an account on the repo which allows nothing more than that.
Thus the cookie-passing isn't strictly necessary anymore, but it would be a nice-to-have to avoid having to expand this auth code (which is about 18 months old and being ported from another, very similar, project) to know about the fossil CGI environment. On the other hand, it's actually quite nice, in terms of maintenance and project encapsulation, to be able to host the CGI via fossil-ext rather than having to rely on a separate Apache-served CGI script.
Reminder to self: make sure this works in conjunction with the JSON login API, so that the login process can be cleanly integrated with the /ext-side front-end bits. That API can/does set the login cookie because it lacks the level of indirection which /ext requires.
(4) By Richard Hipp (drh) on 2020-12-12 15:26:31 in reply to 1 [link] [source]
Now fixed on trunk. Check-in 1cff8d318232ecfc.
(5) By Stephan Beal (stephan) on 2020-12-12 16:19:33 in reply to 4 [link] [source]
Now fixed on trunk.
Thank you very much :). i will deactivate my "fossil-aware" additions and try this out at the soonest opportunity.
(6) By Stephan Beal (stephan) on 2020-12-12 16:29:29 in reply to 4 [link] [source]
Now fixed on trunk.
Sending cookies from /ext CGI confirmed fixed/functional :).
Thank you again :).