On Tue, Feb 19, 2002 at 06:52:07PM +0100, Milos Prudek wrote:
The only information in the cookie is the browser ID -- just a unique key to retrieve the session data saved on the server. The key is NOT cryptographically secure -- capturing the key would enable you to steal a session if the application didn't check for that. This is intended,
This raises an interesting question: How do you check in the application if section was stolen?
Generally, you don't. The easiest way to prevent session theft is to encode the stream, that is, use https. This is not strictly true. You can invalidate the sessionid on the both server and client when the transaction is done and issue a new one. In that way, your session holder will certainly detect id theft. He completes his transaction, the sesionid is invalid, and error is raised. Unfortunately, the user is as likely to blow it off as a bug, as think that it is actually a security problem.... Also, note that a cookie is not the only way to propagate a sessionid; it is just a convenient one. It is equally possible to store the sessionid as hidden data (but it is much more work to make sure that the sessionid appears in every form where it is needed.) Hidden variables and such make more sense when you start thinking less about sessionid (valid for a long time and many interactions), and more about a transactionid (valid for only a few interactions, typically only long enough to gather all the information needed to complete a single transaction). Jim Penny
-- Milos Prudek
_______________________________________________ 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 )