[Seaside] Authorization, cookies, etc.

Avi Bryant avi@beta4.com
Sun, 16 Jun 2002 13:07:50 -0700 (PDT)


On Sun, 16 Jun 2002, Jim Benson wrote:

> However, in standard web tradition, it's also OK to identify a user through
> the use of a cookie. I realized I don't know how to do that code wise. I
> know there's support in there somewhere for cookie support, but I don't know
> how to use it. I noticed this to be missing on the Comanche side also,
> there's really no simple "Here's how to get a cookie, here's how to set it"
> example that I was able to find.

That's because Comanche has pretty poor support for cookies - in
particular, it's impossible to have more than one active cookie at a time
with the way Comanche's implemented (cookies abuse HTTP headers in a way
Comanche isn't set up to handle).

This means, for one thing, that you can't both have Seaside using cookies
to manage the session ID, and be using cookies for your own purposes.

> As discussed before, here's where it gets tricky. Seaside uses the session
> ID in the URL, so when it gets bookmarked there's a problem when he comes
> back the next time. On the list a while back there was some talk about
> keeping the session IDs in cookies to keep them out of the way so to speak,
> but when I looked through the code, this support for this feature has
> wandered back out of the code base.

Why does that mean there's a "problem" when he comes back?  When he
returns to that bookmarked URL, one of two things will happen:

- the session has expired and he will be redirected to a new session,
where he will be invited to log in again

- the session won't have expired, the bookmark will work, and he'll
already be logged in from last time (if that's how you want it - obviously
you could expire the log in instead, and maybe remember the username but
ask again for the password)

So it seems like just making sure the sessions don't expire would solve
both of your problems.  In which case, look at using IASegmentCache
instead of IALRUCache for your sessions.

However, if you decide cookies are a better way to go, it's pretty easy to
make cookie support wander back into the code.  I'm just not sure exactly
how you're intending that to work.

Avi