tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Graichen" <>
Subject AW: Session variables in TC 4.0.1 realms
Date Tue, 20 Nov 2001 13:31:18 GMT
I managed my problem to get the session whithin a realm by modifying, writing a custom realm and a custom FormAuthenticator to have an
authenticate() with an additional HttpServletRequest parameter. However, I
will spend some more time to put this into an Authenticator...

The problem that I realized now is that if you login successfully and go
back using the browsers back button and then login again (with the same user
name and passwort, without destroying the session) you get an 404
j_security_check not avaiable! This is also in the original TC4.0
distribution (examples/jsp/security/protected). Is this a known problem or
what am I doing wrong?


-----Ursprungliche Nachricht-----
[]Im Auftrag von Craig R. McClanahan
Gesendet: Mittwoch, 14. November 2001 18:06
An: Tomcat Developers List; Graichen, Andreas
Betreff: Re: Session variables in TC 4.0.1 realms

On Mon, 12 Nov 2001, Andreas Graichen wrote:

> Date: Mon, 12 Nov 2001 12:49:00 +0100
> From: Andreas Graichen <>
> Reply-To: Tomcat Developers List <>,
> To:
> Subject: Session variables in TC 4.0.1 realms
> Hi,
> I'm going to develop an authentication realm (based on FORM
> 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
> 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


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message