On 1/2/06, Clark C. Evans <[EMAIL PROTECTED]> wrote: > - User ID is very different from Visitor ID, all users are visitors; > but the reverse isn't always true. Visitor ID does not require any > authentication, where User ID probably will. Therefore, I think they > should be handled completely independently.
Generally true. There are times, I think, when you do want to know that you're dealing with an authenticated user and you'd want to keep all of that user's history in mind. (Consider Amazon: they track what you do and provide context based on your browsing history whether you're logged in or not. But, if you're logged in, they have your whole history and not just the history you've had as an anonymous visitor.) > - Visitor ID is very similar (if not identical to?)... Session? > Where session has with it an expiration date, an IP address associated > with the visitor, etc. So, perhaps this should just be called > 'session' ? Yes. Stepping back a few weeks, when Jeff and I started talking about identity, I said that i was keen to have something that didn't require sessions. The reason I said this is that I believe it to be possible to create an authentication/authorization system that handles a great many needs and does not require sessions *or* database access on a per-request basis. The advantage to this is that an application that has no server-side state is very easy to scale. This won't handle *all* requirements, to be sure, but that's why the system is and needs to be pluggable. The kinds of things that identity is getting into (and that Jeff is expressing here) are definitely getting into the realm of traditional "session"-type data. The CherryPy folks put a fair bit of work into CP2.1 sessions and there's truly no reason to duplicate that effort. > - I've written a simple signed-cookie mechanism for storing the WSGI > REMOTE_USER and REMOTE_SESSION environment variables and any other > environment variables you wish; signed cookies do timeout automatically > and are "cluster friendly". It is implemented and tested. > (http://svn.w4py.org/Paste/trunk/paste/auth/cookie.py) > > If TurboGears is already using paste, it is a no brainer: TurboGears is not yet using Paste-Deploy. As of the current CherryPy trunk, CP can currently handle a decent amount of URL mangling on the way in. However, CherryPy still has the notion of a single "root" object that makes it not very functional with paste. Ian has been asking about these things on cp-devel, and I think Remi is going to look into it now that the holidays are ending. It may be possible to remove the single root limitation from CP by using one of their threadlocal proxy objects (so that cherrypy.root can theoretically point to a different object for each request). Kevin
