Adam Gordon wrote:
For background, we actually have two login pages: on is the login page that is running inside our webapp that is running JAAS and POSTs to j_security_check at form submission time. The other page is our company's main website (Apache) and users can log in here too. What we do is perform a GET (either Struts or JAAS does not like doing POSTS w/ parameters - it strips them off) to the default protected resource inside our webapp. What I believe to happen is that JAAS detects that the requested URI is protected so it redirects the user to the login page. I have a large scriptlet block at the top of the JSP page which looks for the login parameters (from the main website page) and uses them to try and authenticate. If it fails, JAAS dumps the user back at the webapp login page with the appropriate error message. If it succeeds, the user is placed at the default (protected) webapp page (or whatever page they originally requested).
Let me get this straight: All pages in your webapp are protected (not available to non-logged in users), so when someone who is logged in on the company's main site tries to get to a page in your webapp, JAAS catches it and sends them to your webapp's login page, which might be able to glean enough details to log them in automagically and then redirect them to the originally requested page in your webapp. So you're relying on JAAS's restriction "non-logged in users can't get to these pages" to insert your webapp's login logic, but if the user *is* already logged in, there's noplace to catch this, so your webapp's login logic gets sidestepped.
If a user is logged in as A and continues (using the site-wide login form) to log in as B, once in your webapp does request.getRemoteUser() return A or B? If it returns A then you have enough information to detect this case.
Since you know how to detect the login parameters from the request, you could put in an interceptor that checks if the login parameter is present, and if it differs from request.getRemoteUser() then you have just detected the problematic case. Invalidate the session and then JAAS will catch that the user is no longer logged in, which will trigger the display of your webapp's login page, which will result in correct behavior.
-Dale --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
