Hello Christoper, thank you for your answer. I observed the same thing as you:
> Also note that the GenericPrincipal nbever actually goes into the > session. After login, snoop the session -- there's nothing in there. I > believe that Tomcat keeps a table of session ids -> Principal objects, > instead of putting that information into the session. (Can someone > confirm... I don't want to spread falsehoods). Therefor I belive you are right when you say it's the wrong approach I tried when I wanted to make GenericPrincipal serializable. It's obviously not as easy as that. Concerning my intentions, I do not want to preserve the session-state between two logins or between more than one session for a given user. I want to preserve the session-state between server-restarts in case of necessary (but normally fast) maintenance operations (changes on certain class-files etc.). So I'm afraid your approach won't help me much. What I would need is a way to manipulate the list the internal table tomcat seems to be keeping of sessionid->Principal mappings. Then I could use the deserialization of some object as a hook to place the correct Principal where it really belongs. Does anyone know how that could be accomplished? Greetings Andreas Mohrig -----Ursprungliche Nachricht----- Von: Christopher Schultz [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 12. November 2003 16:48 An: Tomcat Users List Betreff: Re: Container based authentication and session persistence with Tomca t 4.1.29 Andreas, > I looked up the documentation for org.apache.catalina.realm.GenericPrincipal > (which stores the user information) and noticed that it is not serializable, > i.e. it does not implement the java.io.Serializable interface. But being > serializable is a prerequisite for beeing written to a FileStore (or any > other store most probably). Also note that the GenericPrincipal nbever actually goes into the session. After login, snoop the session -- there's nothing in there. I believe that Tomcat keeps a table of session ids -> Principal objects, instead of putting that information into the session. (Can someone confirm... I don't want to spread falsehoods). > An attempt to patch this class to make it implement this interface has not > been successfull because the GenericPrincipal objects hold references to the > Realm, which is not serializable either (and for some good reasons, it > seems). I believe this is the wrong approach. > Am I just missing something or is this really a problem? Has anyone > accomplished to have persistent sessions with this (or any other) setup and > can give me a hint? > > I'm reluctant to use application based authentication both because of the > work this would cause and because of the security issues involved. Any > feedback would be greatly appreciated. I have recently struggled with container-based AAA, and found the following approach works well for my requirements: Create a Filter that checks to see if there is a Principal available in the request, yet no token in the session to indicate a valid login. In this state, I assume that the user has just successfully submitted the login page. In that case, I perform my "post login" required actions. That is, getting information from my database and putting it into the session. (Note that a Filter instance gets instances of ServletRequest and ServletRespose, so you'll have to check for instanceof HttpServletRequest and cast the reference appropriately. I don't like this too much, but it seems like omy only choice in this situation). In your case, you could couple this technique with two others: 1. Create an HttpSessionListener that will be notified when the user's session expires (or really when the session is destroyed; this may be due to an explicit logout). When a session is destroyed, you can serialize all the session objects to some database (flat file, RDBMS, etc.). Remember to make the data store aware of the user's identity. 2. Use my technique described above to "intercept" logins. When you are in the "just logged-on" state, take the opportunity to locate that user's session datastore and re-load the data back into the session. One last thing: why do you want to save the user's session contents between logins? Why not make everything in the session transient? Or, do you have a lengthy process where users might be logged-out of your system with lots of valuable information in their sessions that is otherwise unrecoverable? -chris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
