struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Cooper" <...@maxcooper.com>
Subject Re: Struts/Container-Managed Authentication Question
Date Thu, 18 Jul 2002 23:49:29 GMT
Hello Mete,

> > One thing that you cannot do with container-managed
> > security is direct the
> > users to the login form page to force them to login.
> > As an alternative, you
> > can protect a page and send users there, so the
> > container will send them
> > through the login form. For instance, if your login
> > form is /loginForm.do,
> > you could make a page (even a redirect back to your
> > home page if you want
> > users to end up there) named /protected.do and then
> > setup a security
> > constraint for that page. Your Login link would be
> > <a
> > href="(contextPath)/protected.do">Login</a> with
> > this setup.
>
> This alternative seems attractive to me, but I'm not
> sure I have truly grasped how it works. I'm going to
> try to paraphrase, so please correct me if I'm wrong:
> - I would provide a link on the public homepage that
> says "Login here" on it. When users click the link
> they would go to a dummy protected page that simply
> redirects the user back to the homepage. Once they
> login through that they're automatically back in the
> homepage and they're logged in!

That's it -- you've got it.

> One thing that I want to implement is providing the
> login form within the home-page to make it a
> single-step job for them, so they'll see the login
> form on the side of the page when they first come in.
> Otherwise there are two steps involved, first click on
> the login link to go to the login form and then submit
> the login form. How do you think I can do that?

I don't know of an easy way to do that with container-managed
authentication. The reason is that the caontainer wants to decide when to
show the login form. If you always show a form, it won't know where to send
the user when you submit. Tomcat chokes on this (rightly so, considering the
spec) and WebLogic sends the user to the context root or something like
that.

I can think of a really ugly (and insecure) way to have the login form on
every page with container-based security:
1. user submits login form from any page
2. server stores username/password in session and responds with redirect to
protected page
3. browser makes request for protected page
4. server responds with login form that you configured, which is setup to
send a redirect to j_security_check?username=user&password=passwd if it
finds the username/password in the session (or perhaps a pre-populated form
that will automagically submit itself)
5. the server accepts the login and sends you to the protected page, which
may just be a redirect back to the home page

Holy crap is that a scary mess! You might be able to clean it up a bit by
using HTTPS (for security), some sort of frames setup (to lessen the chance
of disorienting the user as things flash by), or the login form could have a
"We're processing your login request..." message with the username and
password in a hidden form within the page that submits itself when the page
finishes loading. That might keep the user from freaking out when the screen
starts flashing and it takes a while for the login (lots of back-and-forth
between browser and server). Okay, I am now of the mind that this just might
work.

Note: You can write a filter to mimic container-based security that does
allow you to specify where to send the user after a submit when the login
form was not shown out of necessity. I like the idea of the app using the
methods defined for container-based security (getRemoteUser(), etc.) because
they are standard and you can switch between container-based an filter-based
with no impact to the rest of the app. We have done just such a switch on a
project that I worked on, and it worked great.

> Think about Amazon. You can either be logged-in and
> not logged-in and it will still work. If you're
> logged-in the website treats you like a familiar
> customer, if not just default. That's the exact same
> functionality that I'm trying to implement here. I
> hope this gives a wider picture of what I want to do
> and perhaps you know a better way to do this than how
> I was currently planning on doing it above.

Yes, your app will work like that with this setup. The login scope is the
context, and since both of your sub-apps are in the same context, the login
state is shared between them. Just write your pages to handle both the
authenticated and non-authenticated users. request.getRemoteUser() will
return null if the user is not authenticated.

-Max



--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message