-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 6/25/14, 10:39 AM, Mark Thomas wrote: > On 25/06/2014 15:35, Christopher Schultz wrote: >> Konstantin, >> >> On 6/25/14, 5:23 AM, Konstantin Kolinko wrote: >>> 2014-06-24 21:09 GMT+04:00 Neeraj Sinha >>> <neerajsinha....@gmail.com>: >>>> I am using form based authentication (tomcat 7.0.34) and I >>>> have the implementation of custom realm class which extends >>>> RealmBase class. Inside the getPrincipal() method >>>> implementation, I am calling backend service to save some >>>> login details. I need to pass host name to backend (I have 2 >>>> applications running under different hosts connected to same >>>> DB, so to know the login source of user). Hosts are >>>> configured in server.xml. >>>> >>>> Any help/links/URL much appreciated. >> >>> A Realm is just a DAO class used by Authenticator valves. The >>> idea is that a Realm can be shared between web applications >>> (by placing it at the Host or Engine level). If you want access >>> to the request, you should implement an Authenticator. >> >>> There have been some discussions on changing APIs of >>> Authenticators and Realms to be more friendly for extension, >>> but nobody came up with a specific idea. >> >> I have some code laying around for extending RealmBase to allow >> changes to the password-derivation algorithm, but it wouldn't >> change the public API of the Realm class in a way that wasn't >> backward-compatible. >> >> Changing Realm to include additional information (i.e. the >> request) would break that API. I can't imagine we'd change that >> API for Tomcat 7 and it's getting pretty late for Tomcat 8 (8.0.9 >> was just voted "stable"). > > See the release notes for which APIs may change and how. For Realm, > we can add new methods and deprecate existing ones but we can't > change or remove existing methods. Understood. For the same of argument, let's say that we add a new method: public boolean authenticate(String username, String password, HttpServletRequest request) Since it's not abstract, it's backward-compatible, at least from a build and runtime perspective (e.g. no NoSuchMethodError will occur). However, if we add that method, it makes sense that we might use it. And if a client has overridden authenticate(String username,String password) then their method doesn't get called anymore. Adding a method like setRequest(HttpServletRequest) would be reasonable, except that Realm objects are shared and expected to be threadsafe, so that's not going to work. For securityfilter, what "we" implemented (before my involvement) was a second interface (with a method that includes HttpServletRequest) that could be optionally implemented. If the second interface was implemented by the Realm, then the alternative method was invoked. If the optional interface was not implemented, then we called the "old" method. The above is really the only good way I can think of off the top of my head to provide extra information to the Realm in a completely backward-compatible way. A bad way I can think of would be to provide the extra information as a thread local variable that the Realm implementation can sniff. I feel like using threadlocal in this way is simply a lazy way to avoid passing objects in the traditional way (i.e. on the stack). There is also the complexity introduced by the fact that there are different authenticate() methods for every type of authentication (basic/form, digest, and SSL). That means that we basically need 4 flavors of the same method(s) with extra data being passed-into the method. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTquFMAAoJEBzwKT+lPKRYp+8P/RqN5Dhs31ijnLCqIl5rfPK+ UAgtUueapxSU2yMGHC8u9Lh95uhfWhnHXMo+3LDNDlgM/mF0K0Otad9wNot2BN+C 8wCqvkthHkX6nOVulDghnCtmlBTOVDcdQbzuzJxxeitEwfho/iQnZsFfB4xZN5ID sK13CYSVjWB+eSz7esLNGX6SfG6QK1UWktaVlgbvHho9ezCDNo45Elg5+xVAYsBl snPgqDgeIypBBuRe6EcUB8wxy5/Mfqq7hwQBWb1mGYq7Plu3vvtyP4Ng2G1jp5tk awhlE86FhSHlNhW6s2l2dVs3JCNcn6albMvr04kxGaKMoMQGkHWLSk+D+vF/JDHX mwn4NKb7gfzOqcDaNeOOe8yqEhAeSKIBpzvQKL9yjW3kmKFcuH9ihp9ETZbXM8IQ +ejyEH/JP8NcdhgjKSW6rVKhq1eQhSAnjahQbFg2C6yL0pGbR35wlrAE+xR0eb2x nG2ombckvsopBtbAS0SnKnybSk+kDvFujpeWYL6F4cPBYcRCZLYa9bWe77ewVmXk FJZg98g5Vu+E8qDFs32zUlAsQShlxFX+1CIhi+riUx06IeahVAxLwZlo61nbAn3K 8TmvtK/eKle76XoF+2aI0nHLUiuAsGJZaQ39svPs2TEFK0L3MRJVhBLp+b8u5qGo 2yKirH7okrznvxWajst6 =9iw2 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
