[Zope] [Summary/expansion] Preserving Settings during a user's session

[Martijn Pieters]

This thread has meandered back and forward a bit for a while now.. There
are really two subjects in this thread:
- The immediate solution to the problem Jeff Nielsen has of storing user data
- The question Paul asked if this should be generalized, and how.
I would like to expand on the ideas on generalizing sessions. I'll try and
summarize what was said up to now and add my own ideas at the same time.
This has grown to be practically a proposal:

We are talking about, what I'll call 'Client Sessions', that is, the
simulation of a stateful connection over a stateless protocol like HTTP.
I'll call them Client Sessions to avoid confusion with Zope Sessions, which
are objects that encapsulate a series of changes. I'll leave it to DC to on
names here =).

**Requirements**
A Client Session should:
- Be native to Zope (I really miss support for this in Zope, Paul!)
- Be transparent to the application 
- Be specific to one client (a browser being used by hopefully one user)
- Store information, related to this client
- Expire after a configurable amount of time
- Allow initialisation and clean up methods

**Passing the Session ID**
There are three ways that a Client Session ID (SessID) can be passed
between client and server: 
- By cookie
- As part of the path to the object that is being called (somewhere
inserted into http://myserver.domain/path/to/object/or/method)
- As part of the query data (POST data or the part of a GET request after
the ?)

I personally would prefer the "part of the path" method, as this can be
reasonably transparently be automated by Zope, and will work on all
browsers, including those of people blocking cookies (This is sometimes
done by firewalls or administrators outside the users sphere of
influence!). Cookies can then be reserved for identification of users and
storage of preferences in between sessions (which can also be done manually
by the user if no cookies are accepted). Amazon.com is a well know public
example of this combination.
The third method requires either constant rewriting of all outgoing HTML
(so that all URL's referring the Zope application will contain the SessID
in the query string, and forms have the required hidden field), or the
application programmer will have to add the session ID to all his code by
hand, thus defeating the transparency.

If we really want to be fancy, Zope could support both cookies and the path
method, where the application developer could choose between either, even
on a client by client basis (unless "client supports cookies" use
path_method). This is the way the Sun's Java Servlet Session API works.

**Format of the SessID**
For creating the SessID, there are enough algorithms to create a unique ID.
The only limitation is that the characters should be allowed within a URL.

When using cookies, there is the chance of cookie name clashes. You might
want to have multiple Client Session objects on one Zope server, but the
session data shouldn't cross because the same cookie name has been used. It
could be resolved by using the path attribute of a cookie.

**Client Session Objects**
I imagine that adding Client Session support to a Zope application is like
adding a UserFolder to implement authentication/authorization. Zope would
resolve Client Session Objects the same way it resolves security information.
On this object properties like ID passing method, expiration settings,
starting and ending methods, and default values of data.
When accessed from an application, the object could offer access to the
data of different clients, and information like the number of current sessions.

**Access to Client Session data**
From an application point of view, the Client Session data would probably
best be made available via a similar object as AUTHENTICATED_USER, for
example called CLIENT_SESSION_DATA. It should be a generic dictionary
object with some extra attributes (SessID, time created, times accessed,
etc.). The relevant Client Session object could maybe be reached through
CLIENT_SESSION_PATH. Names here are examples, I know they are a bit long.

**Insertion of the SessID into the path**
For the "part of the path" method to work, the SessID would have inserted
at the base of the Zope application to which the Client Session applies
(see Client Session Objects) and be part of the object name. The root of
the Zope application can then be reached via
http://myserver.domain/Zope/path-of/app*SessID/. This way all relative
paths within a Zope application will work fine within a Client Session. The
DTML variables URLn (URL0, URL1, etc) and BASEn (BASE0, BASE1, etc.) will
of course have to support the SessID part. If for example a Client Session
is active for http://myserver.domain/Zope/path-of/app/, BASE0 would be
http://myserver.domain/Zope, BASE1 would be
http://myserver.domain/Zope/path-of, and BASE2 would be
http://myserver.domain/Zope/path-of/app*SessID. The advantage of using this
method over using insertion as a separate part of the path, is that
relative URL's _out_ of the Zope application will still work, thus allowing
transparency. I used the * as a separation character here, but have chosen
it without actually checking if this would be the right choice. It should
be an illegal object or method naming character, but valid in an URL.

**Starting a Client Session**
When the Zope server encounters a call to an object that (through
acquisition) has a Client Session object defined, but no SessID is present,
it should redirect the client to the same URL with a new SessID. It should
also call the method defined as Client Session start method. This method
should be able to initialize any specific data, and maybe influence the
redirect. This will enable the application to force a user to enter the
Zope application at a specific starting page.

**Ending a Client Session**
If a client hasn't accessed it's Client Session for the specified amount of
time, it's data object should be deactivated and cleaned up. This can
easily be a lazy operation, i.e. only when Zope is processing Client
Session information anyway. Here also, there should be a possibility for
the developer to insert a end-of-session method for cleanup purposes.

**Support within failover systems**
Some people have been talking about sharing data with a central session
server, for failover and load-balancing purposes. I think, that as Zope
doesn't specifically provide support for any load-balancing or failover,
the base implementation of Client Sessions doesn't need to provide this
either. Maybe someone can subclass the Client Session object to support this.

-- 
M.J. Pieters, Web Developer 
| Antraciet http://www.antraciet.nl 
| Tel: +31-35-6254545 Fax: +31-35-6254555 
| mailto:mj@antraciet.nl http://www.antraciet.nl/~mj 
| PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 
------------------------------------------