[Seaside] Session tracking without URL field yet supporting "multi session"

[Mariano Martinez Peck]

On Sat, Oct 3, 2015 at 10:10 AM, Johan Brichau <johan at inceptive.be> wrote:

> 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.
>

Thanks for the idea, I wasn't aware of the sessionStorage. I will read
about it.


>
> 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?
>

Exactly.


> 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
>
>
That's exactly what I ended up doing. But I wanted to be able to have
multiple sessions so the same cookie keeps a list of active sessions. Also,
the session ID stored in the cookie are not the plain session ID because
otherwise it would be very simple to hack. So when a new session ID is
created I create another random token and I store that in a table at server
side. And yes, I keep using _s for tracking. For this, I made a subclass
of WAHandlerTrackingStrategy.

Then I had to make a request filter that would get the session ID from the
_s and check if there is a cookie that holds a correct "token" for that
cookie.

If someone else is interested in this code I can share it. Even more if a
"seaside dev" guy could take a brief look since I suspect I may be missing
scenarios (like document handler expiration vs session expiration).


> But perhaps there is another reason to keep the _s out of the url?
>
> cheers
> Johan
>
> 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,
>
> --
> Mariano
> http://marianopeck.wordpress.com
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20151003/79a89116/attachment.htm