DO NOT REPLY [Bug 36057] New: - The method 'getUserPrincipal()' in class 'org.apache.catalina.connector.Request' returns a not null value after the session has been invalidated and/or recreated

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36057>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36057

   Summary: The method 'getUserPrincipal()' in class
'org.apache.catalina.connector.Request' returns a not
null value after the session has been invalidated and/or
recreated
   Product: Tomcat 5
   Version: 5.5.9
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


When you invalidate the session with a call to the method 'session.invalidate()'
and/or recreate it with a call to the method 'request.getSession(true)', a call
to the method 'request.getUserPrincipal()' continues to return a not null value
just after.

To solve this problem, I think you should reinitialize the value of the field
'userPrincipal' to 'null' in the method 'doGetSession(boolean create)' of the
class 'org.apache.catalina.connector.Request' when the parameter 'create' is
equal to 'true'.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 36057] - The method 'getUserPrincipal()' in class 'org.apache.catalina.connector.Request' returns a not null value after the session has been invalidated and/or recreated

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36057


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-08-06 21:25 ---
Section 12.5.3.1 of the servlet spec is clear that the "logout" of a Form-auth 
user by invalidating the session applies to subsequent requests only.

If you need this fuctionality in your webapp, you can easily get it by 
wrapping the Request at the same time that you invalidate the session.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

getUserPrincipal

[RAamer]

Hi all,

Why are getUserPrincipal and getRemoteUser returnnig null? I know that they
are supposed to return null if the user is not authenticated. What does
that mean exactly? I have Tomcat running locally on my machine. What does
'authentication' mean in my context?

Thanks

RA



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Question about getUserPrincipal...

[The Anenome]

Hi, I posted this question first on tomcat-users, but with no
responses.  I'm hoping one of you guys will be able to answer this
question.  I have been using Tomcat 3.1 in the past, and have been using
the getUserPrincipal().getName() method to determine who has logged in.
I was using apache basic authentication, then using the mod_jserv
connector to forward requests to tomcat.  I have now installed Tomcat
3.3m4, and am using mod_jk.  However, it now appears that
getUserPrincipal() returns null (while getRemoteUser() still works).  Is
there a way I can get the getUserPrincipal() method to return a valid
Principal object based on the Rmote User?  I poked around a bit in the
source code, and it looks like the code that used to set the principal
user has been removed (it used to set it based on the remote user).  I'm
guessing that know it is the responsibility of an interceptor to set the
user principal, but is there any easy way to do this?  Any help would be
appreciated.

Thanks,

Bryan

[Proposal] Fix for getUserPrincipal problem.

[Thom Park]

Hello!

I have, what I believe is a fix for a problem reported by me earlier
with getUserPrincipal, where two separate browser sessions return the
same principal, even when the authorized users are different. The
proposal is this:

In several places in the code there are comments that state that the
adapter that performs the authorize should set both the 'remote user'
and the 'principal', however none of them ever do. My proposal is that
SimpleRealm and JDBCRealm be modified to set the principal at the time
they successfully authorize a user (and call setRemoteUser).

I further suggest that the requestImpl class no longer allocate a
SimplePrincipal should the principal be null. It should be the job of
the authorizing class to allocate the principal, not the requestImpl. To
my mind, the only reason the principal is null (In requestImpl) is if
the user failed authorization. I believe that the routine that sets the
user should also set the principal.

I made the following code changes and successfully tested them on NT
with Tomcat 3.2.1. Could someone please review them and let me know if
they are valid for submission into the 3.2 product as I am not a
committer.

Please advise as to whether my logic (and code) makes sense as this
problem is causing quite a headache with some additional security work
that I am assisting with.

Note as the code is very short, I included the entire methods that I
modified in the three files (SimplRealm.java, JDBCRealm.java and
RequestImpl.java)



Change to SimpleRealm's authorize code (Starting at line 122):

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;
}


Change to JDBCRealm's authorize code (starting at line 472):

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( authenticate( user, password ) ) {
   if( debug > 0 ) log( "Auth ok, user=" + user );
   req.setRemoteUser( user );
   // also set UserPrincipal in request
   req.setUserPrincipal(new SimplePrincipal(user));
   Context ctx = req.getContext();
   if (ctx != null)
   req.setAuthType(ctx.getAuthMethod());
}
return 0;
}

Change to requestImpl's getUserPrincipal code (starting at line 362):

public Principal getUserPrincipal() {
   if( getRemoteUser() == null ) return null;

/*
 principal is now set in [any] one of the adapters that handle
 the authorize function. The servlet spec states that if a user
hasn't been
 authorized, then null should be returned in the principal,
ergo, if the remoteUser
 has been set, then the principal has to have been set as well
-if not then there's a
 continuity failure here and it's best to return null.
 */
   return principal;
}






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

fix for bug 558, getUserPrincipal returns wrong user

[Brian Moore]

I just entered bug 558, but the bug tool ignored the text in the
"how to reproduce" and "workaround" fields, which included my suggested
bug fix:

How to reproduce:
Access the jsp/security/protected/index.jsp
example then access it again as a different user.
getRemoteUser and getUserPrincipal won't match for the 2nd request.

To fix the bug:
In the initRequest() method of tomcat/core/RequestImpl.java
add the line
principal = null;
in with everything else that gets reset.

Brian Moore