Hi Craig,
Thanks for your help on this (and other issues). I am re-working
security in our web application, and previously a user could go directly
to a login page, log in, and be taken to their home, so I can't remove
this functionality. What I did instead was this: I changed my "login"
page to be a JSP that redirects a user to their home page, and then
restricted this page. Thus, when a user hits it, if they are not logged
in they will be sent to the real login page, then login, be redirected
back to my page which then redirects them to their home. This seems to
work pretty well.
My other question is this: Sometimes a person will need to login as one
user, then logout and login as another. Is there anyway for me to
"logout" or "unauthenticate" a user? Another curiosity stemming from
this I have is:
In the Servlet spec (v 2.2, section 11.6) it states that "a servlet
container is required to track authentication at the container level..."
As I understand it, this means my authorization/authentication
information will be saved "across contexts" (ie, I can access a
restricted servlet in a different context wihtout having to login again)
Does Tomcat do this? Where is this information stored, and what is the
right way to invalidate it as I would need to do for a "logout"
process? As far as I can tell it looks like it is just saved on the
Request object (org.apache.tomcat.core.RequestImpl).
I really appreciate all your help.
Thanks once again,
David
"Craig R. McClanahan" wrote:
>
> David Haraburda wrote:
>
> > Hi,
> >
> > I am implementing the Java Servlet Form based login mechanism in my web
> > application, and had a question. Is it possible for me to have a
> > "default location" that a user goes to when they login?
>
> You can do such things at the application level, but container-managed security
> will not do it for you.
>
> Have you ever signed up for a subscription-based web site that uses BASIC
> authentication? What happens is that the username/password dialog box pops up
> -- you answer the questions -- and are then forwarded to whatever URL you
> originally asked for (without having to resubmit the request).
>
> The form-based login mechanism simulates a popup by remembering your original
> request, and then automatically executing it after you have authenticated
> yourself. The user experience is pretty much the same thing.
>
> > In many
> > instances, a user will go directly to the login JSP, rather than
> > requesting a web resource first (which then causes Tomcat to display the
> > login page, and then redirect back to the resource after
> > authentication). If they haven't requested a resource, I'd like the
> > login to take them to their "home" (different roles have different homes
> > in my application). The only way I see right now is to check and see if
> > session.getAttribute( "tomcat.auth.originalLocation" ) is null, but that
> > seems rather naughty... is this the only way of doing it. I have
> > written my own Realm object (that extends BaseInterceptor) for
> > authentication/authorization purposes. Could something be done in
> > there?
> >
>
> The way I program a webapp that uses container-managed security is to never
> explicitly reference the login page (if any) at all. That servlet container
> will do the right thing to authenticate a user, the first time that a protected
> page is requested, if and only if the container does not already know who the
> user is.
>
> This approach means I can switch between authentication methods (BASIC, DIGEST,
> FORM, or CLIENT-CERT) with zero changes to my application logic.
>
> From within the app, you can tell whether the user has been authenticated or not
> by calling request.getRemoteUser() or request.getUserPrincipal().
>
> >
> > Thanks once again for the help,
> >
> > David
> >
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
--
David Haraburda - [EMAIL PROTECTED]
Outsourcing Center - Providing Insight Into Outsourcing
972-980-0013 x736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
