David, Christopher Thank you for sharing your thoughts.
It seems to me that there is no standard solution to this problem, but you agree with me that the problem exists. As I mentioned before, I came up with a solution that looks promising. Here's a rough description, I'd welcome your opinions/concerns: - a custom valve contains the whole implementation - requests to the servlet/URI "j_security_check" are intercepted - for intercepted requests the current session is destroyed and a new one is created: -- snip -- ... request.getSession().invalidate(); request.getSession(true); ... -- snap -- - to have a proper redirect to the originally requested page the original request has to be copied from the old session to the new one. I filter out any references to the old session id, although I'm not sure whether this is really necessary. Well, first of all, I'm in the comfortable situation that I'm not interested in any session attributes that existed before the actual login, so this make things easier. Furthermore, it's clearly a homemade hack, but it seems to do the job. Do you think it's worth to open a bug/feature request concerning this issue? For I actually think that this is clearly a task the container should take care of. Thanks. regards, christoph --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
