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 ------------------------------------------