Thom,
Thanks for the detailed explanation and the solution. I am facing the same
problem using jdbcRealm on tomcat3.2.1. Has anyone reported this as a bug
and do we expect to have a fix soon? I am a new tomcat user and have never
attempted to make code changes or never tried compiling tomcat source.
Please help..
Rajesh
>From: Thom Park <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: Auth bug in 3.2.1?
>Date: Thu, 12 Apr 2001 22:31:26 -0700
>
>Hi Marc,
>
>I saw this problem in 3.2.1 as well - I made a fix for it in the tomcat
>that
>ships with the Borland AppServer but
>couldn't get anyone to comment on the fix in the main code-line
>(essentially
>I'm not a commiter so couldn't submit the fix)
>
>Here's what I found:
>
>The following code is in org.apache.tomcat.core.RequestImpl.java:
>
> public Principal getUserPrincipal() {
> if( getRemoteUser() == null ) return null;
> if( principal == null ) {
> principal=new SimplePrincipal( getRemoteUser() );
> }
> return principal;
> }
>
>Notice the call to SimplePrincipal - this creates a new SimplePrincpal
>object
>(i.e. a java.security.principal) using the
>name associated with the remote User call.
>
>I found two problems with this approach -
>
>1. The username used was not that of the current user - it was of the
>previously authorized user - subsequent users after the first one to be
>authorized
> didn't get changed the reason for this is that the only time we
>refresh
>the principal with a new user, is if the principal was null, but, in this
>case, it wasn't
> the principal still held the previous user's principal..
>
>2. If you were using a custom Realm for authorization (e.g. LDAPRealm),
>then
>this 'new' principal wouldn't be valid for that authorization object.
> If the servlet tried to use that 'special' principal for use with some
>other software, it would no longer be the 'special' principal -it would be
>a
>SimplePrincipal.
>
>
> It blew my J2EE CTS testing out of the water in several places.
>
>I fixed it by doing the following:
>1. in org.apache.tomcat.core.RequestImpl.java: I made the following change
>to getUserPrincipal:
>
> public Principal getUserPrincipal() {
> if( getRemoteUser() == null ) return null;
> // else return principal
> return principal;
> }
>
>And in SimplRealm (and JDBCRealm and any other special Realm Manager) I
>added
>the following to the authenticate method:
>(in bold). My rationale for making this change was that, given it was the
>Realm manager's job to authenticate the user - and, only after
>authentication
>
>should the userPrincipal be set, I moved the responsibility for setting the
>UserPrincipal to the Realm manager.
>
>This also meant that, at any time following successful authorization, the
>current user principal would be correct for the user.
>
> public int authenticate( Request req, Response response )
> {
> // Extract the credentials
> Hashtable cred=new Hashtable();
> SecurityTools.credentials( req, cred );
>
> // This realm will use only username and password callbacks
> String user=(String)cred.get("username");
> String password=(String)cred.get("password");
>
> if( debug > 0 ) log( "Verify user=" + user + " pass=" + password );
> if( memoryRealm.checkPassword( user, password ) ) {
> if( debug > 0 ) log( "Auth ok, user=" + user );
> req.setRemoteUser( user );
> // set principal as well
> req.setUserPrincipal(new SimplePrincipal(user));
> Context ctx = req.getContext();
> if (ctx != null)
> req.setAuthType(ctx.getAuthMethod());
> }
> return 0;
> }
>
>Anyway, that's the story behind this particular problem.
>
>There's also a bug in support for security-role-links but that's another
>story ;-)
>
>-Thom
>
>
>Marc Palmer wrote:
>
> > Hi,
> >
> > I'm a relative tomcat newbie but have discovered what looks to me like a
> > bug in the simple tomcat-user.xml authentication interceptor.
> >
> > In a nutshell:
> >
> > In tomcat-users.xml I have 2 users, in 2 different roles, let's say:
> >
> > "john" has role "manager"
> > "jane" has role "clerk"
> >
> > They auth fine, my servlet is protected using this scheme, everything is
> > beautiful.
> >
> > However, when a (real life) user exits their browser (to clear auth
> > credentials) and opens a browser again on the same PC and goes to my
>site
> > and logs in as a different tomcat user, the user Principal remains the
> > same as the previous request, but the role changes!
> >
> > Step by step:
> >
> > 1) User logs in as "jane". Servlet prints "user = jane, role=clerk"
> >
> > 2) User closes and re-opens browser window.
> >
> > 3) User logs in again, this time as "john". Servlet prints "user = jane,
> > role = manager".
> >
> > So, basically getUserPrincipal is not changing, for some WEIRD reason.
> > Role changes ok, so auth is happening, but it's like the auth
>interceptor
> > is caching principals by IP or something.
> >
> > AFAIK this is not a problem with the browser (IE5) because I have
> > rebooted in between logins and the problem still occurs. In addition,
> > keeping a second auth attempt (that shows incorrect user principal) open
> > in the browser and restarting tomcat and then pressing REFRESH on the
> > browser sends the CORRECT principal to my servlet – so it looks like the
> > browser is sending the right credentials.
> >
> > Am I being silly, or is this a boo-boo?
> >
> > Cheers
>
>--
>http://www.borland.com/newsgroups
>http://www.borland.com/devsupport/disclaim.html
>
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
