sharing sessions through links..

>
> hey, guys..
>
> one quick question after watching the seaside movie last night..
>
> pretend i have an application like ebay written in seaside..
>
> so, i log into my account..
>
> check my bids..
>
> then, i do a search for something..
>
> during that search, i find something my friend would really like..
>
> so i send the link to my friend..
>
> now.. suppose he immediately clicks it (i sent it over IM..)
>
> does he now have full access to my session, including my account
> information?

>>>>>> "Julian" == Julian Fitzell <[hidden email]> writes:
>
> Julian> Unless you take action to prevent it, yes. This problem isn't unique
> Julian> to Seaside, of course; any system with session keys in URLs will be
> Julian> have the same problem. You can, of course, configure the session key
> Julian> to be stored in cookies, which eliminates the problem.
>
> Of course, you trade one problem for another there. If you use session
> cookies, you won't be able to have a single browser with two separate sessions
> in two separate windows, because the cookie is browser-wide.

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

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

> On Tue, Oct 28, 2008 at 5:37 PM, David Farber <[hidden email]> 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.
>

> On Tue, Oct 28, 2008 at 12:59 PM, Julian Fitzell <[hidden email]> wrote:
>  
>> On Tue, Oct 28, 2008 at 5:37 PM, David Farber <[hidden email]> 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
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>    
>
>
>
>  

>>>>>> "Dave" == Dave Bauer <[hidden email]> writes:
>
> Dave> Hi, I have been lurking for a long time, interested in seaside, but
> Dave> working with other web apps right now. That said, I have experience
> Dave> developing this type of system. The fact that the session identifier
> Dave> is not in a cookie doesn't really matter here. You need two cookies
> Dave> anyway. One for user identity and one for session identity. This way
> Dave> you can timeout a session, for example and require reauthentication,
> Dave> or require reauthentication for certain actions, such as amazon.com.
> Dave> Of course the exact details depend on your application.
>
> No, you don't need two cookies --- you need only one cookie, as I demonstrated
> my magazine article
> (http://www.stonehenge.com/merlyn/WebTechniques/col61.html). You can't count
> on a cookie going away as a means of timing out of session, since the browser
> can do whatever it wants and client-side software can lie. So really, all you
> need to do is distinguish this browser from all other browsers, and then use
> server-side state to manage what that actually means. Fortunately, in Seaside,
> we have an easy place to put server-side data, and time it out. Much easier
> than when I was doing this with Perl.
>