> My
> thoughts are that my
> module would actually replace the method which authenticates based off
> information in the principals.xml or would this method work
> in conjunction
> with principals.xml (so that if i use FORM authentication it
> uses my custom
> module but BASIC would refer to principals.xml)? Is this
> corret. I am more
> interested in replacing the use of principals.xml simply
> because of the
> volume of accounts I am dealing with. Would / could this be
> application
> scope (instead of server scope)?
>
I am using Resin, and if you look at the login example that is included you
can see how it works. What you do is implement a custom 'Authenticator'
class, and then specify that class as your Authenticator in web.xml. You
implement your custom class to do whatever you want, it has an
'authenticate(user,password)' method, which you implement to return a
Principle object if the user and password match. How you check for a match
is entirely up to you, you could implement authenticate() to look it up in a
local database, do some RMI, or whatever you want.
> So, in this case, would I still define the HTTP
> authentication type as being
> "FORM" in the web.xml? I am a bit unclear of this. My
I have only tried 'FORM', but my understanding is that FORM/BASIC etc. only
affects how the presentation is implemented. By the time it gets to your
'Authenticator' class, the information is always just passed in as
'authenticate(username, password)'
I don't know anything about principals.xml, but I assume that if this works
in Resin then the default 'Authenticator' uses it. Any 'Authenticator' you
implement yourself would replace that functionality.
But like I said, I'm just guessing on that one.
Note: The 'Authenticator' way of doing things is Resin specific, for some
reason this was not included in the spec, which seems strange to me because
as soon as you implement a solution based on one vendors way of doing things
then you are stuck with them. The Resin way of doing it seems very flexible.
I tried figuring out how ServletExec did it and I couldn't after an hour so
I gave up.
Sam
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
