On Sun, 28 Jul 2002, Eddie Bush wrote:
> Date: Sun, 28 Jul 2002 01:11:16 -0500
> From: Eddie Bush <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: Struts/Container-Managed Authentication Question
>
> Here's something that comes to mind. It's certainly less than idea,
> however it would provide a fair work-around:
>
> Create a directory and place a security-constraint on it. This
> directory would contain pages that did nothing but redirects. You would
> sit down and plan out from where your users could login, and where they
> should be sent to when they login from that page/url. Set your
> JSP/whatever pages up to redirect accordingly. You'd have a
> proliferation of files though - OR - how is this:
>
> Set up a page specifically with a security-constraint. Obviously the
> user in the above scenario will have to be led to the login by a link -
> this scenario would be no different. Your link would be dynamic and
> snag the request parameters out of the URL -- and tack one additional
> one on: the url you wish to redirect to once you authenticate. Now,
> your "let the user login" page would cause authentication to occur.
> Then they get to see the page/action/watever you pointed them to that
> caused the login to begin iwth. From THIS page/action/whatever you
> could get the parameter of where to send the user, and send them
> wherever you please - done deal.
>
> Why would this not work, Craig? (After following this for several days
> and mulling it over rather heavily, I see no reason it would not work,
> but, knowing you are far more knowledgable on this topic than am I, I
> expect there to be a reason :-)
>
> HTH someone - and is a viable option!
>
If you are using form based login, the thing to remember is that the
container is going to replay the *original* request (complete with any
request parameters it included). So including the parameters on the
original hyperlink (to the protected page) is probably the way to go --
that parameter can tell the redirect page where to go next.
Sample scenario -- assume the following:
* index.jsp is the home page of your portal, with a "Log On" hyperlink
(you would display this only if the user isn't logged on yet).
* The destination of the "Log On" link would be something like:
/protected/logon.do?return=/index.jsp
* This assumes you have a security constraint on "/protected/*".
* The logon.do action would do nothing but grab the "return" parameter
and create an ActionForward to return to it.
Now, when the user presses the "Log On" link, the container will show them
the logon page and collect the username and password. When the logon
action is executed, it will return control to the index page with the
now-logged-on user information available.
The same principle can get extended to have a "Log On" link on any other
page you want as well. For example, on mainmenu.jsp the link would be:
/protected/logon.do?return=/mainmenu.jsp
instead.
Note that, under *no* circumstances, do you ever create a link to
"j_security_check" itself. That's a magic incantation reserved for the
container, and only for use on the login page itself -- it's not for us.
> Regards,
>
> Eddie
>
> P.S. - It would be portable too, I think!
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
