So I think I have it working and I didn't have to redirect the user,
which is good because that wasn't working anyway. I don't know if it
was JAAS or Struts, or what, but the login parameters were being
stripped from the request so they never got to the login page.
How I got it to work was this:
I added a filter that looked for the login parameters on the request and
if the login was different from the login of the currently authenticated
user I retrieved the user's instance of their LoginModule (which I set
on the user principal in the login() method in the LoginModule
instance), called the logout method, which cleared the user's
information from the session (though it's not exactly clear how), and
then invalidate the session. For whatever reason, invalidating the
session wasn't sufficient to actually invalidate the session. The
user's information was still being persisted in the LoginModule instance
so my guess is that when the user tried to log in as another user, it
was still using the old user information bean.
The result of this is that if user A is logged in and authenticated and
this user attempts to log in as user B, we log out user A but since B's
login parameters are lost, user B is dumped to the login page where they
have to log in again. We can live with this for now since the only
reason we're implementing this fix is to prevent our CSR's and sales
team from accidentally forgetting to log out as one user and then try to
log in as another and do something to the first user's account when they
are thinking it's the second user's account.
I think ultimately, the solution is going to be to not use JAAS and
implement our own authentication solution since it's pretty clear that
either we're not using JAAS correctly, or it's just not capable of doing
what we need it to do.
Thanks for all the feedback.
--adam
Dale Newfield wrote:
Adam Gordon wrote:
I think the solution is going to be to redirect the user to the
default main page manually w/ the login parameters and JAAS should
take over from there...hopefully.
Except a redirect must be to a GET, not a POST, and it would be
unfortunate to include the login credentials in a GET as they would
then appear in history/logfiles...
...there's no way to do in code in your filter right where the problem
case is detected the same stuff you do in a script on your login form
page?
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
