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

[Esteban A. Maringolo]

2015-10-03 12:35 GMT-03:00 Mariano Martinez Peck <marianopeck at gmail.com>:
> 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 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.


Esteban A. Maringolo