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