I just uploaded an Experimental Sessions Product to the Contrib section on zope.org. This is code I was using to explore the concept of users session/shopping carts for the upcoming ZCommerce API that I'm working on. It's no where near done, I want to get back to writing the API docs, but I thought some of you might get a kick out of it. Here's a teaser from the comments in the source code: The Session Object WARNING!!! This is a reference implementation only. I wrote this to explore session concepts and to get a better idea of what I could or could not do with Zope's security model. This code by no means is complete pretty or even that useful. But it has proven that the session concept is valid. What is a session? A session object is an object that behaves like a folder in zope. If you access <Session FolderId>/docLogin via the web, the session folder will validate your username and password based off of the first acl_users folder that it finds via acquisition. Once the user has been authorized the Session Folder creates a brand new Session Instance and stores the user information in the Session Instance. Whenever an object is accessed through the Session Instance the user is equivalent to the user that originally logged in. In effect the authorization information is stored in PATH_INFO instead of a cookie or using standard HTTP authentication methods. Session Instances will/should be automatically deleted if the user has been idle longer than the time to live property. The advantages to this scheme are. (Of course most of this is not implemented in this sample) * A user can be logged in as more than one person at a time, without having to restart there web browser. * An admin can get a list of all the people currently logged into Zope. * You can limit the amount of times the same user id is logged into Zope at once. * The Session Folder should be able to use any type of acl_users folder, so authentication can be done against the User, UserDB, or UserLDAP already or any other custom User Folder. Because the user is only looked up once, Zope does not have to constantly go back to the data source for every page request and perform authentication like it does now. * Sessions can time out values so a user can be logged out if they are inactive for to long. i.e. They leave there computer unattended, they will be logged out. * Sessions can be used to store state information between web requests so that the user's current IP address can be stored within the session which can prevent people from hijacking sessions. Also makes it really easy to implement a shopping cart object. =) * The scheme is token based, which means that the user name and password aren't passed around in the clear, so it might be more secure. Of course the session would have to be created under SSL for maximum protection, but then once the session has been created the session could be accessed using normal HTTP for speed. * There's many more, but I'm tired of typing. --------------------------------------------------- - Scott Robertson Phone: 714.972.2299 - - CodeIt Computing Fax: 714.972.2399 - - http://codeit.com - ---------------------------------------------------
A session object is an object that behaves like a folder in zope. If you access <Session FolderId>/docLogin via the web, the session folder will validate your username and password based off of the first acl_users folder that it finds via acquisition. Once the user has been authorized the Session Folder creates a brand new Session Instance and stores the user information in the Session Instance. Whenever an object is accessed through the Session Instance the user is equivalent to the user that originally logged in. In effect the authorization information is stored in PATH_INFO instead of a cookie or using standard HTTP authentication methods. Session Instances will/should be automatically deleted if the user has been idle longer than the time to live property.
The advantages to this scheme are. (Of course most of this is not implemented in this sample)
One important one that I forgot. * No need to trick/coerce/plug/patch/or otherwise beat your web server into passing authentication information to your Zope process. --------------------------------------------------- - Scott Robertson Phone: 714.972.2299 - - CodeIt Computing Fax: 714.972.2399 - - http://codeit.com - ---------------------------------------------------
participants (1)
-
Scott Robertson