Core Session Tracking 0.9 Released
Hi Folks, A new version of the Core Session Tracking product (the first one in six months!) has been released. Core Session Tracking is a Product which allows you to easily associate transient data with anonymous users. The product is available from http://www.zope.org/Members/mcdonc/Products/CoreSessionTracking. To upgrade from prior releases, just remove the "old" CoreSessionTracking product directory and install this one as per the install instructions in the help/CoreSessionTracking.stx document. A list of changes since the last version is: - Took advantage of securityinfo module and new BTrees modules. As a result, CST 0.9 is incompatible with releases of Zope prior to Zope 2.3.2. - Objects are now acquisition-unwrapped before being placed into session storage (thanks to Matt Hamilton) - A SessionData object's __setitem__ may now be called from a Python Script, it failed previously with a security error. - Fixed bug in SessionDataManager security assertions which made it impossible to change security parameters (thanks to Uwe C. Schroeder). - Fixed constructor number of parameter bugs (thanks to Chris Withers). - Fixed bugs that made isTokenFromForm, isTokenFromCookie, and isTokenNew methods virtually useless (thanks to Frank Tegtmeyer). - added flushTokenCookie method, which deletes the token cookie from the client browser with prejudice. This method is useful when you want to start out completely fresh with a different token. - Fixed bug which caused a "TypeError: loop over non-sequence" at startup under Zope 2.4.X in the Interfaces module which caused the product to not be initialized properly. (Thanks to Chris Withers and Joachim Werner). - Added multithread test cases to testSessionDataManager. - SessionFanout _getleaf method made more efficient by making allowed_hashes a dictionary (thanks to Anthony Baxter). - Added 'getName' alias to SessionData's 'getId' method for compatibility with code written for SQLSession (thanks to Anthony Baxter). - SessionDataContainer keys are now required to be strings (thanks to Anthony Baxter). - Added a new method to SessionDataManagers, "getSessionDataByKey", which provides a way to obtain an arbitrary session data object by feeding it a key (as opposed to getSessionData, which always obtained the session data object related to the current token). A user needs to possess a special permission to be able to do this. - Added conflict resolution to (RAM-based, internal) SessionStorage. - Made internal data container use "LowConflictConnection" class for its ZODB connections. This class operates differently than the standard Connection class because it doesn't raise "read" conflict errors. - Removed "AutoExpireMapping" class and merged its functionality into SessionDataContainer. - Removed "SessionFanout" module (unecessary because we're not trying to support pre-2.3.2 Zopes). - Refactored tests slightly. - Added SessioningPermissions and common modules. Thanks! -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
On Thu, 2001-10-04 at 23:31, Chris McDonough wrote:
Hi Folks,
A new version of the Core Session Tracking product (the first one in six months!) has been released. Core Session Tracking is a Product which allows you to easily associate transient data with anonymous users.
Is this still on track to be incorporated into Zope 2.5? Michael Bernstein.
CST is still on track to be incorporated in 2.5. This is a release for folks who don't want to go to bleeding edge 2.5 (folks who are currently using CST under Zope 2.3.2 - 2.4.1) as soon as it comes out. Michael R. Bernstein wrote:
On Thu, 2001-10-04 at 23:31, Chris McDonough wrote:
Hi Folks,
A new version of the Core Session Tracking product (the first one in six months!) has been released. Core Session Tracking is a Product which allows you to easily associate transient data with anonymous users.
Is this still on track to be incorporated into Zope 2.5?
Michael Bernstein.
-- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
Chris McDonough wrote:
A new version of the Core Session Tracking product (the first one in six months!) has been released.
...and there was much rejoicing :-)
- SessionDataContainer keys are now required to be strings (thanks to Anthony Baxter).
Why must they be required to be strings? cheers, Chris
Chris McDonough wrote:
On Sun, 07 Oct 2001 15:45:28 +0100
Why must they be required to be strings?
Because I say so. ;-)
I shall consider myself 'told' ;-) Chris PS: SessionDataContainers are the things that sit on web pages and in cookies identifying users right? In which case, I see no reason (or possibility) for them not to be strings...
The definition of a session data container is in the docs. The keys of a session data container, each of which represents a particular session, are (in the current implementation) derived from the session token, which comes out of the request in a cookie or a formvar, and is a string.
PS: SessionDataContainers are the things that sit on web pages and in cookies identifying users right? In which case, I see no reason (or possibility) for them not to be strings...
Chris McDonough wrote:
A new version of the Core Session Tracking product (the first one in six months!) has been released. Core Session Tracking is a Product which allows you to easily associate transient data with anonymous users.
Hi Chris, I've noticed that often (not always :-S) when an object in the same ZODB as a CST 0.8 Internal Data Container is edited, the container dumps all its session information. Has anyone else experienced this? Has it been fixed in 0.9? cheers, Chris
On Sun, 07 Oct 2001 16:46:37 +0100
I've noticed that often (not always :-S) when an object in the same ZODB as a CST 0.8 Internal Data Container is edited, the container dumps all its session information.
Has anyone else experienced this? Has it been fixed in 0.9?
I hadn't had a bugreport like this.... how are you putting objects into the same ZODB as an internal data container? The ZODB that stores an internal data container is a RAM-based storage meant only for session data. Are you somehow getting a hold of this and putting things inside of it? There was a bug where, using the ram-based data container under concurrent load, multiple objects could be created, each of which thought it was the canonical version of the session data object. It would manifest itself, for example, by shopping carts implemented with CST seeming to "drop" their contents randomly.. Is this maybe what you mean? - C - C - C
Chris McDonough wrote:
I hadn't had a bugreport like this.... how are you putting objects into the same ZODB as an internal data container?
No, sorry, I wasn't very clear. Basically, I have a filestorage as the main ZODB storage. I 'Add' a Session Data Manager to this using the drop down list. I'm using this SDM's Internal RAM storage for session information. Quite often, when I edit, say, a DTML method in the ZODB to which the SDm was added, the SDM drops it's session data. However...
There was a bug where, using the ram-based data container under concurrent load, multiple objects could be created, each of which thought it was the canonical version of the session data object. It would manifest itself, for example, by shopping carts implemented with CST seeming to "drop" their contents randomly.. Is this maybe what you mean?
...it sounds like this, although it happen under extremely light load (two users) too :-S Any ideas? I'm gonna give 0.9 a go soon and I'll let you know if the problem goes away... cheers, Chris
- C
- C
- C
participants (4)
-
Chris McDonough -
Chris McDonough -
Chris Withers -
Michael R. Bernstein