[Seaside] sharing sessions through links..

Julian Fitzell jfitzell at gmail.com
Tue Oct 28 21:10:15 UTC 2008


On Tue, Oct 28, 2008 at 10:05 PM, Nevin Pratt <nevin at bountifulbaby.com> wrote:
> Nevin Pratt wrote:
>>
>> Boris Popov wrote:
>>>
>>> Nevin,
>>>
>>> It already does, see senders of #checkCookiesField for more detail,
>>>
>>> Cheers,
>>>
>>> -Boris
>>>
>>>
>>
>> Ah, OK!  A sender of #checkCookiesField is WASession>>performRequest:, and
>> the browser check seems to be done as follows:
>>
>>   aRequest fields includesKey: self checkCookiesField
>>
>> Thanks!
>>
>> Nevin
>
> WASession>>useSessionCookie
>      ^ cookiesEnabled
>       and: [self application useSessionCookie]
>
>
> So, apparantly 'cookiesEnabled' is exactly what I want, and I don't have to
> do the browser check code I mention above.
>
> However, cookiesEnabled is set to 'false' under the following conditions:
>
>   ((aRequest fields includesKey: self checkCookiesField)
>           and: [aRequest cookies isEmpty])
>       ifTrue: [cookiesEnabled := false].
>
> My question is: why do we care if 'aRequest cookies isEmpty'?  Why should
> that have anything to do with whether or not the browser accepts cookies?

Because if it accepted it, it should send it back to us. That's how we
know whether they are supported. The check is a bit vague though. I
just rewrote this in 2.9 to fix this problem, eliminate the creation
of a second session for users who don't have cookies enabled, avoid
having to check for _c on every request, and simplify the code a lot.

The new behaviour is to redirect (to a continuation) with a session
cookie and then check whether the session cookie matches the key in
the URL. If not, we disable cookies for the session.

Julian


More information about the seaside mailing list