Still no luck looking through the logs. I turned authentication to 99 and I get all sorts of info, but nothing that would suggest what is going on.
Simply returning null from authenticate() should work? -----Original Message----- From: Bongiorno, Christian [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 3:41 PM To: 'Tomcat Users List' Subject: RE: How to bring back pop-up with BASIC authentication Thanks for responding. I am using TC 4.0.1. in web.xml under <auth-method> I have BASIC. I created a custom Realm, that's all. I will crank the debug up and take a look. -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 3:18 PM To: Tomcat Users List Subject: RE: How to bring back pop-up with BASIC authentication On Tue, 13 Nov 2001, Bongiorno, Christian wrote: > Date: Tue, 13 Nov 2001 15:21:44 -0500 > From: "Bongiorno, Christian" <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > Subject: RE: How to bring back pop-up with BASIC authentication > > You email gives good insight into some things. I am returning null in > Realm.authenticate() for a failure. This only brings up the access denied > page. So then, I need to change the authenticator for this webapp? I never > changed it to being with. You did explain that I need to respond with 401, > but how? Getting closer. I will look some more now giving new info > Let's step back a step and catch me up on the details. * Which Tomcat version are you using (just want to confirm that we're talking about Tomcat 4)? * Which authenticator are you using? I only described how the standard BASIC Authenticator works, not what your custom one might want to do. (This choice is determined by whatever you specified for <auth-method> in web.xml.) * Have you turned up the level of debugging detail to help figure out what is really going on? You can do this in server.xml: <Context path="/..." docBase="..." debug="99"> </Context> The last will log a bunch more information about the processing actually being performed by the authenticator, and help you understand what is going on. Check the output logs in the "logs" directory. > Chris > Craig > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 13, 2001 2:55 PM > To: Tomcat Users List > Subject: Re: How to bring back pop-up with BASIC authentication > > > On Tue, 13 Nov 2001, Bongiorno, Christian wrote: > > > Date: Tue, 13 Nov 2001 13:48:17 -0500 > > From: "Bongiorno, Christian" <[EMAIL PROTECTED]> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > > Subject: How to bring back pop-up with BASIC authentication > > > > Can someone explain to me how I can tell tomcat from with in my custom > realm > > to prompt the user again for login is their password should fail? The > built > > in realms all do this, but for the life of me I can't figure out how this > is > > being done in the code -- I have been over it several times. > > > > (This is the Tomcat 4 version of the answer.) The key point - it's NOT > the Realm that prompts or reprompts the user -- it's the Authenticator > that does this. > > A Realm is simply a "user database". The various Authenticators acquire > the username and password to be checked by some means specific to that > authenticator. Then, they try to validate the user by calling > Realm.authenticate(username, password). If the Realm returns null, that > means the user was not recognized. What happens next is totally up to > that Authenticator. > > The Authenticator for BASIC is the easiest to understand > (org.apache.catalina.authenticator.BasicAuthenticator). Once it is > determined that authentication is required, it does the following: > > * Have we authenticated a user already for the current > session? If so, just reuse that identity. (This caching > saves a lot of effort, especially when your Realm connects > to a remote database or directory serer). > > * Were the username and password included with this request? > If not, send back an HTTP 401 status, which triggers the > browser to put up the login dialog box. > > * Are the username and password valid? This is checked by calling > Realm.authenticate(). If not, send back a 401 again (which > will cause the browser to reprompt the user). > > * Is there a session for this request? If so, cache the > authenticated Principal so we can use it next time. > > * Update the current request so that getRemoteUser(), getUserPrincipal(), > and isUserInRole() will return the correct results based on the > authenticated user. > > (Warning -- don't try to understand the code in FormAuthenticator unless > you want to go cross-eyed :-). > > Getting back to your original question, all your Realm should do is return > null to the authenticate() call for an invalid username or password. The > Authenticator selected for this webapp will do the rest. > > > Any help would be appreciated. > > > > Chris (new to the group) > > > > Craig > > > > -- > > To unsubscribe: <mailto:[EMAIL PROTECTED]> > > For additional commands: <mailto:[EMAIL PROTECTED]> > > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]> -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]> -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
