Hi! Could anyone, please, explain why Tomcat's session serialization is implemented the way it is? As far as I can see in StandardSession.java the user's principal is deliberately skipped when serializing/deserializing a session. Why? In my opinion this can cause undesired behavior. Imagine the following situation. A web application is protected using form-based authentication. For every logged in user (i.e. for every session, which is valid and not new) there is a session attribute, which contains some user-specific data (e.g. user preferences like background color etc.). That data is initialized from an external source (e.g. database) when the user logs in. Now imagine that the session gets serialized and deserialized. (In real life this can be triggered by restarting the web application). After that the session is still valid (although represented by a different object instance) and it contains the same (deserialized) user-specific data. So everything looks good. But the session does not have a user principal any more, so the next request from the user is redirected to the login page. And here it comes. There is nothing that prevents the user from typing different login/password and if those are valid then it means the existing session will have a new user associated with it, while it still has all its attributes from the "old" user. As a result this is likely to cause not only user's confusion, but also saving the user-specific data in the wrong place in the database (when session is invalidated). Not to mention potential security problems that can raise from the ability of the user to access another user's information stored in the session object attributes. Moreover, in my opinion this breaks the very concept of a session as something bound to a particular user. In practice it is not very hard to work around this problem, for example by creating a filter, which will check user name for every request, but that would usually have negative impact on the application's performance. And still, the user is usually not aware of any possible session serializations/deserializations and I believe he should not be asked to re-login unexpectedly (from his point of view). I suppose there must have been certain reasons why user principal is not serialized. I wonder what those might be. And don't you think the problem I have described is worth fixing?
__________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
