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
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 boris@deepcovelabs.com 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 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
boris@deepcovelabs.com
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 Seaside@lists.squeakfoundation.org 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
On 12/21/06, Boris Popov boris@deepcovelabs.com 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
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
seaside@lists.squeakfoundation.org
-
Avi Bryant -
Boris Popov