Hello again folks! I just downloaded and tried out Core Session Tracking. Let me just say that I am impressed. This is so much nicer than manually setting cookies... Or trying to, and failing. :-) 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? 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? 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. -- Jérôme Loisel Lévinux: GNU/Linux dans les communautés à Lévis
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. ;-)
(There is also the more common DOS case where a malicious script hitting a session-write method repeatedly will cause RAM consumption to increase without bound too. This may be ameliorated to some degree if you use an external session data container in a disk-based storage, because it doesn't need to have all of its objects in RAM at once). ----- Original Message ----- From: "Chris McDonough" <chrism@digicool.com> To: "Jérôme Loisel" <jerome@levinux.org>; <zope@zope.org> Sent: Saturday, March 03, 2001 4:51 PM Subject: Re: [Zope] Core Session Tracking questions
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. ;-)
_______________________________________________ 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 )
Chris McDonnough -- 03/03/2001, 16:51 :
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.
I have been thinking about this... There are several cases in which a site needs to tack user information. In some cases, the site needs to store security-sensitive user info locally... Your current CST code fits that bill very nicely. But often, you just want to store user preferences. These preferences need not be secure so can be stored on the client... And you want to keep those for as long as someone visits your site, so storing it on the server is actually troublesome. To fill this need, people often manually set cookies. But I hate manually setting cookies. I often bump into problems when I try to do so. On the other hand, I love the simplicity of CST. And I wonder: could CST not be used to accomplish both goals via the development of a cookie-based session data manager? You would have a data manager which stores all information client-side via cookies. The data could be stored much longer, months instead of hours. And it would not impact resources, RAM or filesystem. I would not use this to store security-sensitive data about logged-in users, but I would definitely use it to remember which skin an anonymous user preferred. Is that at all possible? Will we see something like this someday? Just wondering. Thanks for CST, it's great. Cheers, Jérôme Loisel -- Jérôme Loisel Lévinux: GNU/Linux dans les communautés à Lévis
I have been thinking about this... There are several cases in which a site needs to tack user information. In some cases, the site needs to store security-sensitive user info locally... Your current CST code fits that bill very nicely.
Geez. It does? It's not very secure... nobody should be using any session manager to store sensitive data for very long. For a long discussion about this, see the zope ml archives around November of last year. If you mean however, that you store it in a session data object temporarily until it is written to a user-related datastore, this is an acceptable risk for lots of folks.
But often, you just want to store user preferences. These preferences need not be secure so can be stored on the client... And you want to keep those for as long as someone visits your site, so storing it on the server is actually troublesome. To fill this need, people often manually set cookies.
Yes... we have this problem on Zope.org. There are thousands of orphaned accounts.
But I hate manually setting cookies. I often bump into problems when I try to do so. On the other hand, I love the simplicity of CST. And I wonder: could CST not be used to accomplish both goals via the development of a cookie-based session data manager?
That's an interesing idea. Except that cookies are usually limited to ~ 4000 characters on the client. You can't stuff much data into 4000 characters. It'd be pretty neat, however. Care to try to implement it? ;-) If not Jerome, anyone else?
You would have a data manager which stores all information client-side via cookies. The data could be stored much longer, months instead of hours. And it would not impact resources, RAM or filesystem. I would not use this to store security-sensitive data about logged-in users, but I would definitely use it to remember which skin an anonymous user preferred.
Is that at all possible? Will we see something like this someday? Just wondering. Thanks for CST, it's great. Cheers,
Not from me in the near future. I'm trying desperately to get another CST release out the door with the features it already has. ;-)
That's an interesing idea. Except that cookies are usually limited to ~ 4000 characters on the client. You can't stuff much data into 4000 characters. It'd be pretty neat, however. Care to try to implement it? ;-) If not Jerome, anyone else?
I just created a simple class with 20 integers, 20 floats, and 20 strings of 48 characters each. Pickled, the object was 1358 characters long, and run through zlib.compress, it was all of 382 bytes long. That is an awful lot of data for only taking up less than 10% (compressed) of the available storage in a cookie. Fill a file with 4000 characters and see just how much stuff that is. You could also potentially work out a mechanism so that the object gets split across multiple cookies if it is too large. I don't think any browser has a limit on the number of cookies settable by one site. I have attached my goofy test class, just so you can see what it looked like. It probably isn't the cleanest solution, but it can certainly be made to work. I think most applications wouldn't even need the compression step. I've never actually used the CSM, just codeit's Session product, so perhaps I am barking up the wrong tree... --sam -- --------------------------------------------------------- A lot of things wrong with society today are directly attributable to the fact that the people who make the laws are sexually maladjusted. -- from "I Seem To Be a Verb" by R. Buckminster Fuller, 1970. class Test: def __init__(self): self.int0 = 34567 self.int1 = 12345 self.int2 = 34567 self.int3 = 34567 self.int4 = 34567 self.int5 = 34567 self.int6 = 34567 self.int7 = 34567 self.int8 = 34567 self.int9 = 34567 self.int10 = 34567 self.int11 = 12345 self.int12 = 34567 self.int13 = 34567 self.int14 = 34567 self.int15 = 34567 self.int16 = 34567 self.int17 = 34567 self.int18 = 34567 self.int19 = 34567 self.float0 = 34567.123 self.float1 = 34567.123 self.float2 = 34567.123 self.float3 = 34567.123 self.float4 = 34567.123 self.float5 = 34567.123 self.float6 = 34567.123 self.float7 = 34567.123 self.float8 = 34567.123 self.float9 = 34567.123 self.float10 = 34567.123 self.float11 = 34567.123 self.float12 = 34567.123 self.float13 = 34567.123 self.float14 = 34567.123 self.float15 = 34567.123 self.float16 = 34567.123 self.float17 = 34567.123 self.float18 = 34567.123 self.float19 = 34567.123 self.blah0 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah1 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah2 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah3 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah4 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah5 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah6 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah7 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah8 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah9 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah10 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah11 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah12 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah13 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah14 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah15 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah16 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah17 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah18 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" self.blah19 = "lksj lskj fdslkj lfdkj ldskj sfdlkj dslkj sfdlkj" Python 1.5.2 (#1, Dec 8 1999, 21:20:51) [GCC 2.95.2 19991024 (release)] on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
from test import Test blah = Test() import cPickle pkl = cPickle.dumps(blah) len(pkl) 1358 import zlib item = zlib.compress(pkl) len(item) 382 len(blah.blah0) 48
Sam said:
I just created a simple class with 20 integers, 20 floats, and 20 strings of 48 characters each. Pickled, the object was 1358 characters long, and run through zlib.compress, it was all of 382 bytes long. That is an awful lot of data for only taking up less than 10% (compressed) of the available storage in a cookie. Fill a file with 4000 characters and see just how much stuff that is. You could also potentially work out a mechanism so that the object gets split across multiple cookies if it is too large. I don't think any browser has a limit on the number of cookies settable by one site. I have attached my goofy test class, just so you can see what it looked like. It probably isn't the cleanest solution, but it can certainly be made to work. I think most applications wouldn't even need the compression step. I've never actually used the CSM, just codeit's Session product, so perhaps I am barking up the wrong tree... --sam --
Cool... IIRC, 20 cookies per site can be set. The question is this (assuming you split across data cookies): over a 28.8k link, do you want to wait at most 80K of data to be sent back and forth from the server on each request which sets session data? In most cases, it would be drastically less, of course. I could see this as a really cool session data manager... it's a little twisted, but it'd be fun. If you're at all interested, Sam, the sdm interface is well-defined.
participants (3)
-
Chris McDonough -
Jérôme Loisel -
sam gendler