Hi, thanks for replying, yes, this question is also posted on SO.
You did actually help me understand the problem better, yet, I cannot resolve it for the moment. To summarize my findings: I have a principal set in the protected resource. If a request is triggered from the protected resource, the request is no longer equipped with the principal in the listener. When arriving on the jsp, the principal is set again. If I set a breakpoint inside the request listener to trigger on a non null principal, it is never triggered. Hmmm, shouldn't tomcat provide the generic principal from the session before the listener is called, when running form authentication? I gave some details to your questions below. To (1): is additional source required? To (2): Here is the stack when the listener triggers: PortalRequestListener.requestInitialized(ServletRequestEvent) line: 79 StandardContext.fireRequestInitEvent(ServletRequest) line: 6157 StandardHostValve.__invoke(Request, Response) line: 165 StandardHostValve.invoke(Request, Response) line: not available ErrorReportValve.invoke(Request, Response) line: 103 AccessLogValve.invoke(Request, Response) line: 950 StandardEngineValve.invoke(Request, Response) line: 116 CoyoteAdapter.service(Request, Response) line: 421 Http11Processor(AbstractHttp11Processor).process(SocketWrapper<S>) line: 1070 Http11Protocol$Http11ConnectionHandler(AbstractProtocol$AbstractConnectionHandler).process(SocketWrapper<S>, SocketStatus) line: 611 JIoEndpoint$SocketProcessor.run() line: 314 I checked with all requests coming in, but the stack contents is the same for all breakpoints. To (3): I have debugged the FormAuthenticator and found that the request is actually at some point equipped with the correct principal. So the authentication actually works to some extent. I have restructured the main.jsp to do nothing, and it gets displayed properly, genericPrincipal is set. If I call from that page a protected resource, that request has no principal set, but I can see the principal in the session (buried in the StandardSession object). Shouldn't the request receive the principal, as it is requesting a protected resource? To (5): Yes, it is subclass from GenericPrincipal and created by the realm (using new) and returned to the caller of authenticate. I see the principal object with right class name in the debugger at the right place. Mit freundlichen Grüßen Thomas Strauß Geschäftsführer Entwicklung SRS PaperDynamix® WE MAKE PAPER WORK T +49 6251 85 424 - 20 | M +49 174 2110912 SRS-Management GmbH | Berliner Ring 103 | D-64625 Bensheim Geschäftsführer: Detlev Homilius, Thomas Strauß HRB 25262 AG Darmstadt Fon +49 6251 85 424-0 | Fax +49 6251 85 424-14 Wir freuen uns auf einen Besuch in unserem Forum auf XING oder Facebook https://www.xing.com/net/prozessoptimierung/ http://www.facebook.com/srs.management -----Ursprüngliche Nachricht----- Von: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Gesendet: Montag, 26. Januar 2015 11:43 An: Tomcat Users List Betreff: Re: request.getUserPrincipal() is null but StandardSession.principal is set 2015-01-26 11:54 GMT+03:00 Thomas Strauß <t.stra...@srs-management.de>: > Hi, > > we have an issue with later and latest Tomcat versions, that prevent us from > upgrading to a version later than something like 7.0.22. > > We use FormBasedAuthentication with a custom realm. > > This is tested with Tomcat 7.0.57 and JDK 7u76 on Windows. > > My setup has a login form calling the j_security servlet. The custom realm is > called and authentication is successful, a custom principal is returned. > > Tomcat will then forward to the protected resource, and we catch the request > in a RequestListener. > > The problem is, that request.getUserPrincipal() returns null. The debugger > exposes, that the sessionwrapper returned by request.getSession(false) > (instance of SessionWrapper, containing StandardSession) has a field > "principal", that contains the principal returned from my realm. > > I have seen a discussion on the requirement to return a userprincipal on non > protected requests in bugzilla, but the request here is calling for a > protected resource. > > Any idea on why this can happen would be very helpful. Actually, I see it as > a bug, that the request is not authenticated but still served. 1. Source code = ? I see that you have it here: https://stackoverflow.com/questions/28147261/request-getuserprincipal-is-null-but-standardsession-principal-is-set 2. Stacktrace when RequestListener is invoked = ? When the listener is called? Is it called after authenticator valve or before it? 3. Try debugging through AuthenticatorBase.invoke() https://wiki.apache.org/tomcat/FAQ/Developing#Debugging There is code that copies the principal from session into request [[[ if (cache) { ... if (principal != null) { if (log.isDebugEnabled()) log.debug("We have cached auth type " + session.getAuthType() + " for principal " + session.getPrincipal()); request.setAuthType(session.getAuthType()); request.setUserPrincipal(principal); } } } } ]]] 4. This does not reproduce in the default configuration. There is a page in examples webapp that uses FORM authentication. http://localhost:8080/examples/jsp/security/protected/index.jsp If you look into index.jsp it will display "No user principal could be identified." when request.getUserPrincipla() is null. It displays the correct principal name for me. 5. Is your principal a subclass of GenericPrincipal? How do you set it? Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
