Using "Session" to store per-session data.
Rather than passing around lots and lots of data as hidden form fields all the time, I'm planning to extend Scott's Session object to support storing and retrieving of per-Session data. Issues with this: In a non-https environment, it would be rather easy to hijack a session by looking at a cache log. I could store the IP address, but this breaks many cache farms (where a session may come from different IP addresses... :( Is it better to store this in an SQL database, or in the session object itself? I want this to be preserved in the case where Zope restarts, which means I can't just use _v_object type variables. Storing it in the Session object itself means that the ZODB will grow at a stupid rate. Storing it in an SQL database means a bit of a performance hit. Has anyone already implemented something like this? Thoughts? Anthony
At 1:23 pm +1000 13/9/99, Anthony Baxter wrote:
Rather than passing around lots and lots of data as hidden form fields all the time, I'm planning to extend Scott's Session object to support storing and retrieving of per-Session data.
Issues with this:
In a non-https environment, it would be rather easy to hijack a session by looking at a cache log. I could store the IP address, but this breaks many cache farms (where a session may come from different IP addresses... :(
Is it better to store this in an SQL database, or in the session object itself? I want this to be preserved in the case where Zope restarts, which means I can't just use _v_object type variables.
Storing it in the Session object itself means that the ZODB will grow at a stupid rate. Storing it in an SQL database means a bit of a performance hit.
Has anyone already implemented something like this?
Thoughts? Anthony
A plug for my *old* language, PHP3 and its session library PHPLIb. They did it using cookies and an SQL database, and I think that's the way to do it, rather than using the ZODB. The PHPLib library is at: http://phplib.netuse.de/index.php3 hth tone ------ Dr Tony McDonald, FMCC, Networked Learning Environments Project http://nle.ncl.ac.uk/ The Medical School, Newcastle University Tel: +44 191 222 5888 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2
Tony McDonald wrote:
A plug for my *old* language, PHP3 and its session library PHPLIb. They did it using cookies and an SQL database, and I think that's the way to do it, rather than using the ZODB. The PHPLib library is at: http://phplib.netuse.de/index.php3
I wonder why you think the ZODB isn't the place to do this? If it is because of the versioning issue: 1) You can create a special datastructure that doesn't version on every commit, but instead perhaps every minute. Think of it as halfway between volatile and persistent. 2) One of these days we'll come out with a non-versioning Storage class, plus allow people to mix Storages in the same process. 3) Then again, perhaps people could live with the 20 byte or so growth on each Session commit. --Paul
At 7:37 am -0400 13/9/99, Paul Everitt wrote:
Tony McDonald wrote:
A plug for my *old* language, PHP3 and its session library PHPLIb. They did it using cookies and an SQL database, and I think that's the way to do it, rather than using the ZODB. The PHPLib library is at: http://phplib.netuse.de/index.php3
I wonder why you think the ZODB isn't the place to do this?
Really because I'm understanding the situation to be somewhat akin to the 'counter' problem. I may well be misguided in that, and am probably misusing the ZODB because of it (I'm using it for holding DTML objects, External methods and ZSQL methods mainly). The other reason is that I don't understand enough about the Storage class you mention.
If it is because of the versioning issue:
1) You can create a special datastructure that doesn't version on every commit, but instead perhaps every minute. Think of it as halfway between volatile and persistent.
2) One of these days we'll come out with a non-versioning Storage class, plus allow people to mix Storages in the same process.
This would be highly useful - the PHPLIb libraries were invaluable to me when I was working with PHP (holding variables across sessions, and authentication being the main reasons I used the library).
3) Then again, perhaps people could live with the 20 byte or so growth on each Session commit.
That doesn't seem *too* high a price to pay. cheers, Tone. ------ Dr Tony McDonald, FMCC, Networked Learning Environments Project http://nle.ncl.ac.uk/ The Medical School, Newcastle University Tel: +44 191 222 5888 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2
participants (3)
-
Anthony Baxter -
Paul Everitt -
Tony McDonald