[Seaside] Session tracking without URL field yet supporting
johan at inceptive.be
Sat Oct 3 13:10:30 UTC 2015
They only way I can think of is to store a session id in the browser sessionStorage, which is unique to each tab.
However, I do not think anyone has done so yet.
The question that pops to my mind is: why do you want to hide the _s in the url? If this is about security, it’s probably because you do not want someone to copy/paste the url and hijack the session?
You can prevent that by not using the session to track authentication, but a cookie. In other words:
- use a cookie for authentication (i.e. always require the cookie to be present)
- keep _s for session tracking
-> a user will need both the session id in the url _and_ the cookie to work
But perhaps there is another reason to keep the _s out of the url?
> On 01 Oct 2015, at 15:20, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
> Hi guys,
> I am evaluating some improvements for an app, and I would like these 2 features:
> 1) Do not expose _s in URL
> 2) I want to be able to open multiple different seaside sessions from different tabs of the browser.
> I was checking the WACookieSessionTrackingStrategy subclasses but of course that is not gonna work because if I have multiple sessions opened in the browser, at #cookieFromContext:ifAbsent: there is no way I can guess which is the real session I must answer for that request.
> I am not against using cookies, but I cannot see how that could work. Anyone has a workaround?
> As a second thought, I saw WASslSessionTrackingStrategy (my site does run with HTTPS over nginx) which looked interesting. Has someone used this before? I have read a couple of problems with it:
> " An interval that is too short can cause a premature termination of a session.
> Also, some Web browsers might have their own timers that affect the lifetime of the SSL session ID. These Web browsers may not leave the SSL session ID active long enough to serve as a useful mechanism for session tracking.
> I seems the timeout can be easily set in nginx. But I am wondering about what it says about browsers killing inactive SSL sessions IDs. Have anyone experienced this?
> Thanks in advance,
> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>
> seaside mailing list
> seaside at lists.squeakfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the seaside