[Seaside] sharing sessions through links..

[Dave Bauer]

On Tue, Oct 28, 2008 at 12:59 PM, Julian Fitzell <jfitzell at gmail.com> wrote:
> On Tue, Oct 28, 2008 at 5:37 PM, David Farber <dfarber at numenor.com> wrote:
>>
>> On Oct 27, 2008, at 5:15 PM, Julian Fitzell wrote:
>>
>>> The last (which is what Randal was suggesting) is probably the most
>>> reasonable compromise in that you can leave the session key in the URL
>>> and therefore have multiple sessions open and passing the URL to
>>> somebody else doesn't give them access to the session. This (over SSL)
>>> is probably pretty secure. But you still can't decide that the site
>>> isn't working in Firefox and copy and paste the link over to IE.
>>>
>>> Without some way to actually confirm the identity of the user behind
>>> the keyboard, of course, we have no choice but to make a compromise
>>> somewhere.
>>
>> Forgive me if I am ignorantly suggesting something that won't work in
>> Seaside, but I would try this:
>>
>> 1) Keep a token identifying the user in a cookie.
>> 2) Leave the session info in the url.
>>
>> Since the session is still in the url, you can still have multiple sessions
>> in the same browser.  And since the user token is in a cookie, I can paste
>> the URL into any browser where I've already authenticated.
>
> Well that's basically what Randal was suggesting and is, I think, the
> best we can do currently. It still only identifies the browser,
> though: if a user walks away from the browser or someone sniffs the
> cookie value, we have no way of knowing that it isn't the same user
> anymore. Always using the same key for a particular user does have the
> nice property that they can move sessions between browsers but at the
> additional risk that you now want that cookie to persist for a much
> longer period of time which is bad if the token does get captured.
>
Hi, I have been lurking for a long time, interested in seaside, but
working with other web apps right now. That said, I have experience
developing this type of system. The fact that the session identifier
is not in a cookie doesn't really matter here. You need two cookies
anyway. One for user identity and one for session identity. This way
you can timeout a session, for example and require reauthentication,
or require reauthentication for certain actions, such as amazon.com.
Of course the exact details depend on your application.

You could combine the user identity token with session checking to
timeout a session, or require re-authentication after a certain time
period. Obviously those settings depend on the exact security
requirements of your application. I'd suggest using a hashed value in
the identity cookie and to vary the cookies value randomly. Of course
this again depends on the exact security requirements of your
application, but in general it's a good idea.

Dave

> Julian
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>



-- 
Dave Bauer
dave at solutiongrove.com
http://www.solutiongrove.com