Hi, how about extends the "org.apache.catalina.authenticator.AuthenticatorBase"? or extends "FormAuthenticator" if you are using form based. The base class is actually a Valve, thus provide the "Request" object access. And to use it, just simply add as a valve in your context xml file. If I understand it correctly, this will override the default one.
On Tue, Aug 8, 2017 at 9:09 AM, Mark Thomas <ma...@apache.org> wrote: > On 08/08/17 14:01, Christopher Schultz wrote: > > Mark, > > > > On 8/8/17 8:49 AM, Mark Thomas wrote: > >> On 08/08/17 13:44, Christopher Schultz wrote: > > > >> <snip/> > > > >>> I have no problem with Tomcat having access to the IP address. I > >>> just want Tomcat to make that IP address available to the > >>> authenticator component in some way. > > > >> https://bz.apache.org/bugzilla/show_bug.cgi?id=59750 > > > >> Implementing that in a way that is truly backwards compatible > >> requires a little thought. > > > > I agree that backward-compatibility is a significant issue, since the > > Realm interface hasn't changed since ... well, ever. > > > > How about cheating and using a ThreadLocal? > > > > try { > > tl.set(theRequest) > > authenticator.authenticate(username,password); > > } finally { > > tl.set(null); > > } > > > > ?? > > Yuck. > > > For SecurityFilter, we added a sub-interface that adds more methods, > > like this: > > > > authenticate(String username, String password); > > authenticate(String username, String password, HttpServletRequest req); > > > > Then, the driver does this: > > > > if(realm instanceof ExtendedRealm) > > ((ExtendedRealm)realm).authenticate(username, password, theRequest); > > else > > realm.authenticate(username, password); > > That could work for 8.5.x and earlier. We can use default methods in > Tomcat 9. > > I was also thinking about the case where a custom component called the > Realm (e.g. custom nested Realms). I'm not sure there is one solution > that can cleanly handle all use cases. We probably need to go with the > majority. > > > If using the HttpServletRequest itself is architecturally distasteful, > > we could use some other kind of data object, or simply > > java.lang.Object (which is a little distasteful itself). > > I have no problem with using the HttpServletRequest. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
