[Seaside] Fallback to support cookie-less browsers

[Boris Popov]

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

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

-----Original Message-----
From: seaside-bounces at lists.squeakfoundation.org
[mailto:seaside-bounces at lists.squeakfoundation.org] 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 <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
_______________________________________________
Seaside mailing list
Seaside at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Seaside.st
Type: application/octet-stream
Size: 2357 bytes
Desc: Seaside.st
Url : http://lists.squeakfoundation.org/pipermail/seaside/attachments/20061221/d8f8cb54/Seaside.obj