[Seaside] Fallback to support cookie-less browsers

[Avi Bryant]

On 12/21/06, Boris Popov <boris at 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