Overview: Unable to login towards a Tomcat UserDatabase Realm when using the HttpServletRequest.login(String, String) method. This feature has worked up until Tomcat 8.5.28 (Worked with Tomcat 8.5.27). The problems occurs when trying to retrieve the Authenticator from the StandardContext. Setup: * New installation of Tomcat 8.5.28 * Use the default Tomcat Realm configuration (UserDatabase) * Add new user to the tomcat-users.xml Steps to reproduce: * Try to authenticate by using the method HttpServletRequest.login(String, String) Expected result: * Login successful Actual result: * Unable to retrieve the NonLoginAuthenticator from the StandardContext.getAuthenticator(). The valve(s) in the pipeline is not an instance of Authenticator (NonLoginAuthenticator). The method will return null, which will cause the Request.login method to throw a new ServletException with the error message "no authenticator". Tomcat version: Tomcat 8.5.28 Additional Information: Might be related to issue 62036 which was part of the Tomcat 8.5.28 release.
I don't get it at this point. The fix for 62036 cannot break this. NonLoginAuthenticator still extends AuthenticatorBase which implements Authenticator.
The problem is that ContextConfig.authenticatorConfig is not appropriate with the login API (which was introduced later). Assuming the webapp has no security constraints, before r1823310 there would be a problem if metadata-complete was true (not very common), but now it's always. Oops. This fix is rather obvious (always set the NLA is there is no login config). The side effect is that a realm is now mandatory (Tomcat has no way to know if an app will call login).
There is an equivalent NullRealm that is used if no Realm is configured. I've back-ported remm's fix for 9.0.x. Fixed in: - trunk for 9.0.6 onwards - 8.5.x for 8.5.29 onwards - 8.0.x for 8.0.51 onwards - 7.0.x for 7.0.86 onwards
Thanks, I was waiting for a bit of testing before backporting.
Sorry, didn't mean to step on your toes. I know that code fairly well so I was confident your patch was correct.
*** Bug 62142 has been marked as a duplicate of this bug. ***