Fallback to support cookie-less browsers

You know that problem that you can't enable cookies without risking
throwing your clients (and server) into an endless loop of redirects
when said clients have their cookies disabled/disallowed? Here's a first
stab at addressing the issue, details logs below. It's a VisualWorks
fileout, but it's a really tiny set of 3 changes, so I was hoping for a
peer review of some sorts to see if that even makes sense ;)

Cheers!

----- Cookies Disabled Without Fixes -----

curl -L http://localhost:7777/online
curl: (47) Maximum (50) redirects followed


----- Cookies Disabled With Fixes -----

curl -Li http://localhost:7777/online

HTTP/1.1 302 Found
Location: http://localhost:7777/online?_k=BPlZDLES
Set-Cookie: online=SHdxyvpHgSYIuAAN

HTTP/1.1 302 Found
Location: http://localhost:7777/online?_s=ISLgZslhOnSNpxzr&_k=OqbbsbFi&3

HTTP/1.1 302 Found
Location: http://localhost:7777/online?_s=ISLgZslhOnSNpxzr&_k=xXlOiQYU

HTTP/1.1 200 OK
Content-Length: 4582


----- Cookies Enabled With Fixes -----
C:\>curl -c cookie.jar -Li http://localhost:7777/online
HTTP/1.1 302 Found
Location: http://localhost:7777/online?_k=zhwNopRt
Set-Cookie: online=NotjJZEehYAPhKxY

HTTP/1.1 302 Found
Location: http://localhost:7777/online?_k=CgSFaeCy&3

HTTP/1.1 302 Found
Location: http://localhost:7777/online?_k=WHYjcAeu
Set-Cookie: online=NotjJZEehYAPhKxY

HTTP/1.1 200 OK
Set-Cookie: online=NotjJZEehYAPhKxY
Content-Length: 4279

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.


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

Interesting... doesn't that rely on the first request to the session
having some cookies, though (that aren't being set by Seaside)?
Admittedly there always does seem to be cookie cruft being passed back
and forth but I'm not sure it's the best idea to rely on that.  Or am
I missing something?

Avi

On 12/21/06, Boris Popov <[hidden email]> wrote: _______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hmm, lemme look at it carefully again (attached trace.log)

Request 1
5. GET /online (no cookies sent)

Response
16. Location: http://localhost:7777/online?_k=tWrqhMOR
18. Set-Cookie: online=YifYoJwmZkCIMlFu

Request 2
56. GET /online?_k=tWrqhMOR

Response
67. Location:
http://localhost:7777/online?_s=sWgSeVNVeWbixaqs&_k=JsJkMDGz&3

Request 3
106. GET /online?_s=sWgSeVNVeWbixaqs&_k=JsJkMDGz&3

Response
117. http://localhost:7777/online?_s=sWgSeVNVeWbixaqs&_k=Krsohlyu

Request 4
156. GET /online?_s=sWgSeVNVeWbixaqs&_k=Krsohlyu

Response
184. Recv data, 4085 bytes

The way it works, is whenever you walk into a session with a "_k" param
and you supplied no cookies, assume the browser does not support them
and switch that session into a cookie-less mode and start including "_s"
in the URL.

Feels a bit odd, doesn't it?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Avi
Bryant
Sent: Thursday, December 21, 2006 3:27 PM
To: The Squeak Enterprise Aubergines Server - general discussion.
Subject: Re: [Seaside] Fallback to support cookie-less browsers

Interesting... doesn't that rely on the first request to the session
having some cookies, though (that aren't being set by Seaside)?
Admittedly there always does seem to be cookie cruft being passed back
and forth but I'm not sure it's the best idea to rely on that.  Or am
I missing something?

Avi

On 12/21/06, Boris Popov <[hidden email]> wrote:
> You know that problem that you can't enable cookies without risking
> throwing your clients (and server) into an endless loop of redirects
> when said clients have their cookies disabled/disallowed? Here's a
first
> stab at addressing the issue, details logs below. It's a VisualWorks
> fileout, but it's a really tiny set of 3 changes, so I was hoping for
a 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

On 12/21/06, Boris Popov <[hidden email]> wrote:
> Hmm, lemme look at it carefully again (attached trace.log)

> Response
> 16. Location: http://localhost:7777/online?_k=tWrqhMOR
> 18. Set-Cookie: online=YifYoJwmZkCIMlFu

> Response
> 67. Location:
> http://localhost:7777/online?_s=sWgSeVNVeWbixaqs&_k=JsJkMDGz&3

> The way it works, is whenever you walk into a session with a "_k" param
> and you supplied no cookies, assume the browser does not support them
> and switch that session into a cookie-less mode and start including "_s"
> in the URL.

Well, not quite - there are two sessions here (note that the cookie
doesn't match the _s param).  So what you're doing is creating one
session, which sets a cookie as well as the _k param.  When you
redirect it can't find a session param (either in _s or cookie), and
so gives you a new one.  This one has a _k param, and no cookie, and
so disables the cookies.

So, here's the problem: what if someone is using cookies, bookmarks a
URL that has a _k param, then quits their browser and the cookie goes
away.  They open up the browser later and go to the bookmark, and the
first request seaside sees has _k but nothing for the session...
they'll get treated as if cookies were disabled.

Here's the hack I've been using.

WASession>>redirectWithCookies: aCollection
        | response |
        self respond:
                [:url |
                url addParameter: '_ck' value: 'y'.
                response _ WAResponse redirectTo: url displayString.
                aCollection do: [:ea | response addCookie: ea].
                response]

WAApplication>>handleRequest: aRequest
        ((aRequest fields includesKey: '_ck') and: [aRequest cookies
isEmpty]) ifTrue: [^ self cookiesRequired].
        ^ super handleRequest: aRequest

Then you can implement #cookiesRequired to do whatever - in my case I
just display an error message, but you could set a flag in a session
object or something instead...

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

Ah, fair enough, I knew it didn't feel quite right. Here's the adjusted
version that uses your approach to trigger fallback only when the
initial redirect failed to carry the cookies back to Seaside,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Avi
Bryant
Sent: Thursday, December 21, 2006 3:53 PM
To: The Squeak Enterprise Aubergines Server - general discussion.
Subject: Re: [Seaside] Fallback to support cookie-less browsers

On 12/21/06, Boris Popov <[hidden email]> wrote:
> Hmm, lemme look at it carefully again (attached trace.log)

> Response
> 16. Location: http://localhost:7777/online?_k=tWrqhMOR
> 18. Set-Cookie: online=YifYoJwmZkCIMlFu

> Response
> 67. Location:
> http://localhost:7777/online?_s=sWgSeVNVeWbixaqs&_k=JsJkMDGz&3

> The way it works, is whenever you walk into a session with a "_k"
param
> and you supplied no cookies, assume the browser does not support them
> and switch that session into a cookie-less mode and start including
"_s"
> in the URL.

Well, not quite - there are two sessions here (note that the cookie
doesn't match the _s param).  So what you're doing is creating one
session, which sets a cookie as well as the _k param.  When you
redirect it can't find a session param (either in _s or cookie), and
so gives you a new one.  This one has a _k param, and no cookie, and
so disables the cookies.

So, here's the problem: what if someone is using cookies, bookmarks a
URL that has a _k param, then quits their browser and the cookie goes
away.  They open up the browser later and go to the bookmark, and the
first request seaside sees has _k but nothing for the session...
they'll get treated as if cookies were disabled.

Here's the hack I've been using.

WASession>>redirectWithCookies: aCollection
        | response |
        self respond:
                [:url |
                url addParameter: '_ck' value: 'y'.
                response _ WAResponse redirectTo: url displayString.
                aCollection do: [:ea | response addCookie: ea].
                response]

WAApplication>>handleRequest: aRequest
        ((aRequest fields includesKey: '_ck') and: [aRequest cookies
isEmpty]) ifTrue: [^ self cookiesRequired].
        ^ super handleRequest: aRequest

Then you can implement #cookiesRequired to do whatever - in my case I
just display an error message, but you could set a flag in a session
object or something instead...

Avi
_______________________________________________
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