Re: [Zope] ANN: Core Session Tracking 0.7
From: "Chris McDonough" <chrism@digicool.com> A new release of the "CoreSessionTracking" product is out. The product allows you to associate state with anonymous visitors between requests.
I've been wondering about this for a long time. It allows you to associate state with anonymous users. Does this imply that you can't associate state with authenticated users, or that there's another mechanism to do it with authenticated users? In the servlet paradigm, there's a distinction between the HTTP session and authentication. You set up a session with an HTTP request, and thereafter if the session ID is returned to you it's the same session. In that session, the user can choose to login or not. Is this the same thing or is it different?
A new release of the "CoreSessionTracking" product is out. The product allows you to associate state with anonymous visitors between requests.
I've been wondering about this for a long time. It allows you to associate state with anonymous users. Does this imply that you can't associate state with authenticated users, or that there's another mechanism to do it with authenticated users?
There's nothing inherent in the product which prevents you from associating state with authenticated users. It's just not as useful because once they're authenticated you'd probably be better off associating the state with their user object. I've seen a couple of examples of session usage, however, that mix user state and session state... for example, in the ASP world (and I think in the servlet world too), when a session starts and ends, you can associate an event with it. So this allows you to use the session space as sort of a scratchpad for use when a user comes in. At start time, you copy over some user state to the session object (based on authentication information). The user does some stuff, changing the contents of the session state. Then when the session expires, the session end event is called, the state is copied back to the user object. This is something that core session tracking doesn't do because session ids don't expire. There are also a couple of undocumented methods in core session tracking that allow you to associate a session data object with a user's database path. The reason that they're undocumented is because I'm not sure how far I want the tendrils of session tracking to go. This is an area we need help in, but it's probable that this information should probably be associated with the user in another way.
In the servlet paradigm, there's a distinction between the HTTP session and authentication. You set up a session with an HTTP request, and thereafter if the session ID is returned to you it's the same session. In that session, the user can choose to login or not.
Is this the same thing or is it different?
Core session tracking is the same.
servlet world too), when a session starts and ends, you can associate an event with it. So this allows you to use the session space as sort of a scratchpad for use when a user comes in. At start time, you copy over some user state to the session object (based on authentication information). The user does some stuff, changing the contents of the session state. Then when the session expires, the session end event is called, the state is copied back to the user object. This is something that core session tracking doesn't do because session ids don't expire.
Actually, the more I think about this, the more convinced I become that I should offer something this tied to the expiration of the session data object.
state with authenticated users. It's just not as useful because once they're authenticated you'd probably be better off associating the state with their user object.
Wow... I wish Zope supported this. Maybe a proposal for dev.zope.org is in order? How I'd like to see text box widths and top frame preference stored against the user, not the domain name/browser... :-S Cheers, Chris
On Wed, 31 Jan 2001, Chris Withers wrote:
state with authenticated users. It's just not as useful because once they're authenticated you'd probably be better off associating the state with their user object.
Wow... I wish Zope supported this. Maybe a proposal for dev.zope.org is in order?
How I'd like to see text box widths and top frame preference stored against the user, not the domain name/browser... :-S
Oh, no, no, no. I, for example, use at least two different computers with 2 different screen resolutions, so I certainly want to store these preferences in my cookie files (these files are different on these 2 computers, of course). Oleg. ---- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
Oleg Broytmann wrote:
Oh, no, no, no. I, for example, use at least two different computers with 2 different screen resolutions, so I certainly want to store these preferences in my cookie files (these files are different on these 2 computers, of course).
No problem, just have another _user_ preference which says whether ZMI preferences are stored as Browser Preferences or User Preferences. Then you and me can both be happy, even if we're using the same server ;-) cheers, Chris
On Wed, 31 Jan 2001, Chris Withers wrote:
No problem, just have another _user_ preference which says whether ZMI preferences are stored as Browser Preferences or User Preferences.
Then you and me can both be happy, even if we're using the same server ;-)
Right! Give free choice to a user !! (No, I am not about GPL, you know!!! :) Oleg. ---- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Wed, 31 Jan 2001 00:30:40 -0000 Chris Withers <chrisw@nipltd.com> wrote:
state with authenticated users. It's just not as useful because once they're authenticated you'd probably be better off associating the state with their user object.
Wow... I wish Zope supported this. Maybe a proposal for dev.zope.org is in order?
How I'd like to see text box widths and top frame preference stored against the user, not the domain name/browser... :-S
In principle you could do this by spawning a property sheet off the user object for each product and storing attributes in that - and I think that's one of the things that Zpatterns would like to make possible, however in practice I haven't figured out how to do it the way I'd like to without making the LoginManager specialist become the customization specialist for each product. However, Zpatterns talks about products[1] being able to add property sheets onto other object without that object 'knowing', so maybe it is possible, and I haven't figured it out yet (I don't think I'm the only one who finds the jargon make my head spin). On the other hand, they also talk about making property sheets act like data managers so you can define data plugins to handle their individual attributes as being a feature they'll include in 0.50 or something, so maybe it isn't possible just yet. I'm looking to solve the customization problem in the interim by having a given product define a class for their customization data and methods, and have a specialist in the aquisition path manage the data, keyed to the name of a given user object[2]. As a site integrator, I can modify the specialist's data plugins to say something like 'don't get and store the full name and email address in this object, instead, get them from this global data specialist over here'. I think this will solve most of my immediate problems. John [1] Applications/frameworks/whatever-the-kids-call-it-today [2] Or better yet, the user object has a method to return a primary key, so that user objects can change their login name with ease.
Yeah the "dissociating user objects from their user names" problem is the hardest one to solve right now because it requires changes to the core that may have the potential to break 3rd-party user folders which are based on the Zope basic user folder. It's definitely required for a (real) membership system which allows users to change their usernames. However, if you're not concerned about this, you can use the security manager to grab the user: from AccessControl import SecurityManager sm = getSecurityManager() u = sm.getUser() Then you can get the user's folder path (a tuple of path elements plus the user's name): db_path = tuple(list(user.aq_inner.aq_parent.getPhysicalPath())+[user.getId()]) ... and use that as the key into another namespace. It will be guaranteed unique, but it of course can't be changed without adverse effects on this coupling. This is an area of Zope that deserves a lot of attention. ----- Original Message ----- From: "John Morton" <jwm@plain.co.nz> To: <zope@zope.org>; "Chris Withers" <chrisw@nipltd.com> Sent: Wednesday, January 31, 2001 6:01 PM Subject: Re: [Zope] User Sessions
On Wed, 31 Jan 2001 00:30:40 -0000 Chris Withers <chrisw@nipltd.com> wrote:
state with authenticated users. It's just not as useful because once they're authenticated you'd probably be better off associating the state with their user object.
Wow... I wish Zope supported this. Maybe a proposal for dev.zope.org is in order?
How I'd like to see text box widths and top frame preference stored against the user, not the domain name/browser... :-S
In principle you could do this by spawning a property sheet off the user object for each product and storing attributes in that - and I think that's one of the things that Zpatterns would like to make possible, however in practice I haven't figured out how to do it the way I'd like to without making the LoginManager specialist become the customization specialist for each product.
However, Zpatterns talks about products[1] being able to add property sheets onto other object without that object 'knowing', so maybe it is possible, and I haven't figured it out yet (I don't think I'm the only one who finds the jargon make my head spin). On the other hand, they also talk about making property sheets act like data managers so you can define data plugins to handle their individual attributes as being a feature they'll include in 0.50 or something, so maybe it isn't possible just yet.
I'm looking to solve the customization problem in the interim by having a given product define a class for their customization data and methods, and have a specialist in the aquisition path manage the data, keyed to the name of a given user object[2]. As a site integrator, I can modify the specialist's data plugins to say something like 'don't get and store the full name and email address in this object, instead, get them from this global data specialist over here'. I think this will solve most of my immediate problems.
John
[1] Applications/frameworks/whatever-the-kids-call-it-today [2] Or better yet, the user object has a method to return a primary key, so that user objects can change their login name with ease.
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Wed, 31 Jan 2001 18:39:24 -0500 Chris McDonough <chrism@digicool.com> wrote:
Yeah the "dissociating user objects from their user names" problem is the hardest one to solve right now because it requires changes to the core that may have the potential to break 3rd-party user folders which are based on the Zope basic user folder. It's definitely required for a (real) membership system which allows users to change their usernames.
I was going to solve it for my situation by storing login information in a SQL table with a numeric primary key and the login names being mearly unique. I can then expose the primary key in the user object and use it (via a method or whatever) as the relation key - which is exactly what you do between tables in a relational database anyway :-) In the scenario where all the per user data is being stored in the user object itself, then there is nothing for the user name to be relational with, so there's no problem if the username is changed. John
<snip explanation>
In the scenario where all the per user data is being stored in the user object itself, then there is nothing for the user name to be relational with, so there's no problem if the username is changed.
This is true, but for the basic Zope user folder implementation, it's more desirable to keep volatile membership data somewhere else due to the ZODB's propensity to not like to do a lot of writes. So we need to key on something, and it shouldn't be the username, but it can't be anything else currently.
This is an area of Zope that deserves a lot of attention.
Hmmm... I have an idea I know it changes the interface, which is bad, but I think it's needed and provides a pretty generic solution to a lot of problems: How about making user objects implement the mapping interface just like Session Tracking objects do? This could be implemented persistently in the standard acl_users folder, but things like LoginManager could store stuff however they wanted. I know this doesn't solve the problem of users changing their own names (which is what I think you were talking about) but it would make a lot of applications simpler and mean a lot more people could go without the pain of having to learn how to use LoginManager. What have I missed? cheers, Chris
participants (6)
-
Chris McDonough -
Chris Withers -
Gerald Gutierrez -
Gerald Gutierrez -
John Morton -
Oleg Broytmann