I managed my problem to get the session whithin a realm by modifying realm.java, 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? Andreas -----Ursprungliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]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 <[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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
