Fallback

Oct 13, 2009 at 11:40 AM

Hi,

I have managed to get your brilliant tool up and running very quickly, thanks! I have one question which is what is the best way to handle fallback? IE If a user connects from outside the domain or from an unsupported browser. I have managed to get this working by mapping error 401 to a custom jsp in tomcat, from here I can then forward to the standard login page. Is there a better way to handle this?

 

Thanks

 

Neil Musgrove

Coordinator
Oct 15, 2009 at 6:12 PM
Edited Oct 15, 2009 at 6:14 PM

Hello Neil,

You can use Firefox or IE. On Mac, you can also use Safari.

The use of the status 401 is given in the file howto.txt in the directory example. If a URL is protected, the server sends 401 with the header WWW-Authenticate. The client sends a header Authorization. With NTLM, two exchanges between the navigator and tomcat are needed. So you cannot map error 401 to a custom jsp.

If you do not use Spnego, you must use another Realm to authenticate the users. A Realm represents a "database" of usernames, passwords, and roles.

With SSPI, Active Directory (or the local account base SAM) is the Realm. Realm is only used by tomcat when the method "IsUserInRole" is invoked so the application must use a Realm. For that,  I give "WindowsRealm" because the class RealmBase is abstract.

To use a form to authenticate the user, you can use FormAuthenticator. So, your question is: how to use two authenticators? With two Contexts and two deployments? Or with two Engines with two different Connectors? I shall test. 

Dominique Guerin

Oct 16, 2009 at 7:45 AM

Hi,

We have now been using this setup and it seems to work for us. I was thinking about it and the way we have it configured is that if Tomcat were to show a 401 error page (presumably different to sending a 401 to the browser) then instead of showing it's own page, it shows our login page. During the login process Tomcat would not display it's 401 error page even if it is sending a 401 behind the scenes unless the process has totally failed. So as far as I can tell replacing that failure page would not block a legitimate login. Is that right? I wasn't clear in my first message that it is just the error page that is being modified, not tomcat's response to the client.

Thanks very much for your help.

Neil Musgrove

 

PS We have been looking for a library like this for a while and found none that work as easily and as well as this, Thank you!

Coordinator
Oct 20, 2009 at 5:17 AM

Hello,

You can change the error page in the file web.xml, with the tag  error-page.  You can have more information on google

<error-page>

<error-code>401</error-code>

<location>/my401page.html</location>

</error-page>