Ken Johanson wrote: > ... > >>> I'm trying to write a facade API that will call into whatever >>> Realm/Authenticator that the user already has configured (though an >>> abstract/overridden method)... the idea being that no changes to the >>> user's existing auth config or modules are required, nor that the user >>> should need to change out any custom realm/authenticator that they may >>> have written, for mine. So the solution needs to transparently call into >>> some existing method(s) in the 'Base' classes or interface impls.. >> >> To do what? What user requirement are you trying to meet? Technically >> I understand what you are trying to do but not the fundamental why. >> Knowing your ultimate aim may enable people on this list to suggest an >> alternative approach. >> >> Mark >> > > The intent is that a simple library can be deployed into the (at > server/lib or shared/lib), and from any webapp, calling into that > wrapper class will allow the app to authenticate and register the user.. > irregardless of what specific authenticate/realm modules are being used. > > A very simple example, is that I would like for users to login on a html > form, by entering not just their username - but maybe their email > address (any number of them), or pub key (to be hypothetical)... then > its it will be up to the webapp to search a database beforehand, to > lookup the email address or pub key, and get the userid, then pass it to > the auth module if, say, the account is current, the password age isn't > expired, etc. > > All completely independent of what Realm/Authent. is config'd for any > webapp. Only the username and password (and which webapp as implied by > the context path contained in Request).: static boolean > Tomcat5.authenticate(request, response, user, pass); > > Creating and deploying my own version of this class is not feasible, > because : > > -users should have the option to write the account validation logic in JSP > > -Users may already have a custom impl, and should not have to extend or > implement or compile anything in that impl. to support this lib. Be it > their own impl or their choice-use of tomcat JDBC realm. > > Thanks, > Ken
Given users are going to have to modify their app to use this library, not modifying the associated context.xml looks to be a nice to have requirement that is making things more difficult. Removing this requirement opens up a number of alternative implementation options including custom realms. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
