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]
