struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie Bush <ekb...@swbell.net>
Subject Re: Logout in a container-managed security environment
Date Wed, 25 Sep 2002 18:11:04 GMT
Charles McClain wrote:

>Mohan:
>
>I just finished setting up container-managed FORM-based authentication
>and getting it working, based on advice from several people on this
>mailing list.  I'll pass on what I learned, and others can add to it or
>correct my advice.  I'm assuming that you know how to set up
>container-managed FORM-based authentication, and that your question only
>applies to its relationship to Struts.  If that is not the case, you can
>review the replies I received to my original posting, or write back and
>I will provide detail.
>
>Container-managed FORM-based authentication is separate and apart from
>the Struts framework, and indeed can be applied to an application that
>is not based on Struts.
>
>When you set up FORM-based authentication, you specify a login page and
>login error page.  When the user enters a URL that falls within the
><security-constraint> and <web-resource-collection> you specified in
>your web.xml, the container takes over and pops up the login page you
>specified in your <login-config> entry.
>
>Assuming that your login page form specifies "j_security_check" as the
>action, when the user hits the submit button, control passes back to the
>container, which validates j_username and j_password against the
>container's security realm; if they are valid, then the container passes
>control to the <welcome-page> specified in your web.xml.  If they are
>invalid, the container passes control the error page you specified.
>
>Since this validation is performed by the container, you do NOT want a
>Struts ActionForm associated with the login page, nor do you want an
>Action associated with it.  If you have prep work you need performed,
>you should perform it in the Action associated with your welcome page.
>It will get performed when the login passes the container's validation
>and the container passes control to your welcome page.
>
You could get creative in your approach to this.  If my other post ever 
hits the list you'll see an outline for how you can do so.  I *believe* 
I, at one point, had my login/error pages specified as actions, 
actually.  I ... can't recall why I went back to JSPs.  I think I was 
having some stupid errors that had to do with my "tripping" through my 
config (accidental key-in errors) - I believe you should be able to use 
actions to refer to your login/error pages.  Try it :-)  If it doesn't 
work, scratch it.

>It IS useful, however, to have a <global-forward> back to the login
>page, so that your login error page can direct the user back to the
>login page, to re-login after an error, and so that, after he logs out,
>your logout confirmation page can direct him back to the login page.
>Also, your login page and login error page may contain Struts tags.
>
You really should have no direct reference to the CMA-oriented login 
page whatsoever.  You do not have the ability to invoke it directly.

>Since I'm still in the process of converting my app over to FORM-based
>authentication, I haven't completely worked out the interaction between
>the container and Struts as far as subsequent login-checking is
>concerned.  I don't think you need to check the user's login status on
>your JSPs and in your actions, because I think the container will force
>the user to the login page if he tries to enter the app "in the middle"
>via a bookmark or something.  I will be testing this in the near future.
>
>However, I do know that you can gain access to the username and/or role
>via the Jakarta Taglib request library; for example, I originally
>converted my app to container-managed BASIC authentication expressly so
>that I could use the <req:isUserInRole> tag to vary menu and screen
>content based on the user's role.
>
Yes, this is one of the biggest benefits (that I see) of CMA over 
"roll-your-own" approaches.  There are, however, "roll-your-own" 
approaches which can provide this same functionality.  You could take a 
look at securityfilter.sourceforge.net for one possible alternative.  It 
requires a container to be servlet spec 2.3 compliant (filters are a 2.3 
thing), but allows you to actually include your realm in your 
application - and would be a container-independent realm solution.  Most 
containers will let you "roll-your-own" realm (I believe - I know for 
certain Tomcat does, and understand that others will, as well). 
 Whichever way you go, it's still "make-based" login (authentication is 
done by the container, in response to the user requesting a restricted 
resource).  To get "let-based" logins, you have to either do something 
creative, as I've suggested, or resort to implementing your own security 
(authentication) service.  Of course, if you implement your own ... I'm 
not aware of how you could override isUserInRole() etc.  I think there 
are approaches to this using Filters though.

>I apologize for my incomplete knowledge, and as I said, I encourage
>others to correct or add to what I have written, but since no one else
>has yet replied to you, I figured you'd rather have some reply than
>none.  I'll be smarter in a few days, after I've had a chance to fully
>integrate the container-managed FORM-based authentication facility and
>do all my testing.
>
>-- Charlie
>



--
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