On Mon, 12 Nov 2001, Andreas Graichen wrote:
> Date: Mon, 12 Nov 2001 12:49:00 +0100
> From: Andreas Graichen <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Session variables in TC 4.0.1 realms
>
> Hi,
>
> I'm going to develop an authentication realm (based on FORM authentication)
> for TC 4.0.1 which performs a kind of challenge/response task: Put a
> challange into a session variable on the login page (.jsp). The expected
> password would then be the encrypted challenge. Whithin my realm the
> decryption of the response and the verification against the stored session
> variable has to be performed. The problem is that the HTTP request is not
> accessible whithin TC 4.x realms. This was possible in TC 3.x. Is there any
> possibility to access a session variable in a TC 4.x custom realm? Thank
> you.
>
It sounds like you really want to create an Authenticator, not a Realm.
You might also want to look at how DigestAuthenticator (which implements
DIGEST login) deals with encrypted passwords coming in.
Authenticators *do* things -- they actively decide whether a user has
already been authenticated, and challenge him/her if not. And, of course,
they have full access to the request and response (because they are
Valves). The programming model for Valves is similar to that of Filters
at the application level -- so Authenticators can (and do, if you look at
the existing implementations) intercept the request and create
authentication challenges back again.
Realms are just a place to look up users and check their passwords. Think
of a Realm as a database, not a participant in request processing. It's
an interface to *any* underlying storage mechanism -- a black box that
says "yes, this user is valid" or "no, this user is not valid."
In Tomcat 4, these concepts are separate from each other, because you
really want to be able to mix and match *any* Authenticator with *any*
Realm. In Tomcat 3.2, the concepts are mashed together in one class,
which was totally messed up IMHO.
> Andreas Graichen
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
