Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (athena.apache.org: domain of adam.gordon@readytalk.com
 designates 208.50.222.178 as permitted sender)
Message-ID: <4741B287.50106@readytalk.com>
Date: Mon, 19 Nov 2007 08:57:59 -0700
From: Adam Gordon <adam.gordon@readytalk.com>
Organization: ReadyTalk
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Struts Users Mailing List <user@struts.apache.org>
Subject: Re: [struts] JAAS and Struts Re-authentication Question
References: <473A144B.6090900@readytalk.com> <473A35E2.1040801@Newfield.org>
 <473B20CE.9070406@readytalk.com> <fhg2it$5ms$1@ger.gmane.org>
 <473C89CD.2010106@readytalk.com> <473C8FE1.7060208@Newfield.org>
 <473DE5E6.8000108@readytalk.com> <473DF175.90706@Newfield.org>
In-Reply-To: <473DF175.90706@Newfield.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org