Hi Jerome,
First question: Say my cookies are set to last 14 days, but my session data manager only stores session data for 60 minutes... What happens? Say a visitor comes, sets some preferences, leaves and comes back two days later. A new session oject is created. Are the old cookies "imported" in the new object or is the data lost?
The data is lost. The data container timeout determines how long the data sticks around, not the cookie timeout (the cookie contains what you can think of as a "browser id" rather than a "session id", although the docs claim its a sessionid... this is why the docs go into some explanation of this phenomena). In many cases, it's desirable to use a session id as... well.. a session id, instead of trying to use it to associate data with a user for time immemorial. One common pattern is to use a session data object to store data about the user until they log in. Then when they log in, you copy the data from the session data object to an object associated with the user, and then clear the session data, considering the user-associated data canonical.
Second question (not really as important for me): Is a Core Session Trackink-enabled site not more vulnerable to DOS attacks? Are there plans to eventually add sometghing to protect against OOM situations due to DOS attacks, like limiting the maximum amount of RAM used by core session tracking?
Are you allowing people to script DTML or other through-the-web code on your site? If so, then, yes, probably. If not, then yes, perhaps. ;-) There is one failure case in core session tracking that hasn't yet been addressed (even if folks can't script DTML on your site): because session data objects are stored in the ZODB, they are prone to conflicterrors on write. The data structures used by the session data containers are designed to minimize conflict, but in the case that lots of folks come in with the *same* session id at the same time, and they visit a method which writes to that session data object, your site might experience some denial of service due to conflicts hogging the ZODB connections. A determined script kiddie could make this happen pretty easily with a script that fired off a bunch of reader threads that pretended to be clients with the same session cookie, hitting a method which did a session write. Or it could happen if a session-encoded URL was posted to Slashdot. You can minimize the possibility of this happening (especially if you run a public site) by not using URL-encoded session ids. I'd like to minimize the possibility of this failure by writing some code in the session id manager that rejects multiple requests that claim to have the same session id in some very short timespan. But it's a tricky problem, because there could be a legitimate situation in which this could occur. In any case, I haven't yet addressed it.
PS: BTW, thanks again for Core Session Tracking. So far, it looks really cool: powerful and dead simple to use. The documentation in help/ seems needlessly compicated, though.
Hee hee... damned if you do, damned if you don't. Write docs, that is. ;-)