Session tracking without URL field yet supporting "multi session"

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?

cheers

Johan

On 01 Oct 2015, at 15:20, Mariano Martinez Peck <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2015-10-03 12:35 GMT-03:00 Mariano Martinez Peck <[hidden email]>:
> On Sat, Oct 3, 2015 at 10:10 AM, Johan Brichau <[hidden email]> 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 problem with this is how you add the session parameter to requests
(both full and xhr ones)


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

Not a Seaside Dev guy, but if you share it I'll take a look at it.

I think that for preventing session hijacking you don't need to remove
the _s parameter from the query arguments, but instead *add* new
information about the particular client to the session tracking in the
server, like IP, some sort of UA fingerprint, etc.

So if somebody hijacks the session ID, it will be rejected by the
server because it's coming from a different client other than the one
that initiated the session.