-----Original Message----- From: zope-bounces@zope.org [mailto:zope-bounces@zope.org]On Behalf Of Tres Seaver Sent: 23. november 2004 22:37 To: zope@zope.org Cc: Sune Broendum Woeller Subject: [Zope] Re: Invalidating a session, creating a new
Chris McDonough wrote:
On Tue, 2004-11-23 at 15:07, Dieter Maurer wrote:
Sune Broendum Woeller wrote at 2004-11-22 20:43 +0100:
...
>In the zope book, sessions chapter, is written: > >"Manually Invalidating A Session Data Object > >Developers can manually invalidate a session data object.
When a session
>data object is invalidated, it will be flushed from the system,
and will not
>be returned by subsequent references to REQUEST.SESSION or
getSessionData().
>" > >and : > >"...subsequent references to REQUEST.SESSION in this same request will >return a new session data object." > >I would like to be able to invalidate the session object, and
then create a
>new session with a new key, to be accessed in the next request. > >But I find that when invalidating a session data object, I can *still* >access the old session data in subsequent references to
REQUEST.SESSION, in
>the same request that is. I do not get a new session data object, as I >should according to the zope book. And therefore I can not
reference the new
>keys I create in the following requests. > >Has anyone got a solution for this problem ? > >It seems the invalidation goes on "between" requests. > >Is this an error with the sessioning machinery or in the zope book ?
Maybe, it worked in some Zope version. But, it has no chance in a modern Zope:
Sessions are created on demand, i.e. when you access the SESSION object for the first time.
To make this happen, the "SessionDataManager" registers a factory as a REQUEST lazy item under the name "SESSION".
When you access "REQUEST.SESSION", the factory is called to get the real session object and then the session object is stored as normal REQUEST variable. The factory is removed form REQUEST (as the implementors thought it were no longer necessary).
With this description, you can see: you can invalidate the session object but this has no chance to give you a different session object (in the same request).
You would need to change the handling of lazy items in "ZPublisher.HTTPRequest.HTTPRequest" (not allowed to remove the factory) and delete the "SESSION" as normal REQUEST variable to make it work.
I would say, the book is wrong.
Darn. It was meant to work the way it's described in the book. For it to not work this way is a bug. The invalidate method of a session should cause the session data object to be invalidated.
Unfortunately, the "lazy" resolution stuff in ZPublisher also removes the factory from the _lazies namespace, so if the invalidation removed 'SESSION' from request.other it could also never get it from request._lazies in the same request. :-(
It would be good if a tracker issue could be entered about this.
In the meantime, a workaround is to not use REQUEST.SESSION to get the session data, but to instead use something like "context.session_data_manager.getSessionData()" to get the session data associated with the current request.
Wouldn't an adequate workaround be just to clear the session (rather than destroying it and creating one anew)? E.g.:
session = REQUEST.SESSION session.clear() session['key'] = value
Tres.
The suggestion from Tres gets me half the way, but it is not enough since I need to get a new session id. The problem is that the request still holds the old session object. The suggestion by chris, to use "context.session_data_manager.getSessionData()" to get the session after the call to invalidate works - it gives me a new session object, and all is well :) To summarize, this does the trick: s = context.REQUEST.SESSION s.invalidate() s=context.session_data_manager.getSessionData() s['myNewKey']='myNewValue' Should I file a bug report here : http://zope.org/Collectors/Zope ? regards, and thank you for your help, Sune