On Tue, 30 Jul 2002, Joe Barefoot wrote:
> Date: Tue, 30 Jul 2002 12:33:59 -0700
> From: Joe Barefoot <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: Security and Struts
>
> I think your first guess is a pretty good one. Sub-classing the
> ActionServlet is okay, but you could also create an abstract Action base
> class to take of authentication and authorization.
>
> Check to see if the user is logged in via a Role object in the session (if
> there's no Role object in the session, they haven't logged in :) ). If
> they're logged in, call the abstract method (executeAction, or whatever you
> want to call it) which will be implemented by your concrete subclasses.
>
> If they're not logged in, redirect them to your login form/page. Check your
> DB to see if they are a valid user and what role they are, then store this
> info in a new Role object and stuff it into the session. Redirect from the
> login page to your application "home" page or whatever.
>
> To handle which role gets access to what, consider using the "parameter"
> attribute (or I think there's a new "property" attribute too in 1.1) in your
> action-mapping to indicate what role(s) have access to this particular
> action. You can easily check these in your Action base class and allow/deny
> access accordingly.
If you are using container-managed Security, Struts 1.1 (nightly builds)
will do this for you -- see the "roles" attribute in the <action> element.
>
> This will not cause any problems with page bookmarking if every JSP is
> through an Action which subclasses your authenticating Action base class, as
> any conceivable URL would have to go through the base class. This also
> applies to subclassing the ActionServlet or RequestProcessor.
>
> A third option is to use a ServletFilter to do the same. This has the
> advantage of sitting outside of the Struts framework, so you can enforce
> security on other (non-Struts) Servlets and resources if you have them.
> Check out the Servlet 2.3 API and tech. articles for info on ServletFilters.
> You would have to come up with your own declarative role-resource mapping
> configuration in this case, but that is not too difficult. Just use an XML
> file that maps URLs to allowed role names.
>
> Finally, Container-managed authentication/authorization is okay, but it is
> application-server specific and would have to be modified for any port to
> another container.
>
More precisely, the mechanism by which users are registered is server
specific -- your application that just *uses* containe managed security is
100% portable.
>
> peace,
> Joe
Craig
>
> -----Original Message-----
> From: Ryan Cuprak [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 30, 2002 11:53 AM
> To: [EMAIL PROTECTED]
> Subject: Security and Struts
>
>
>
> Hello,
> I was hoping someone would have some advice on securing a website using
> struts. I am developing a webapp that has to be secure (password protected)
> and which restricts access to different parts of the site depending on the
> roles a user possesses. The roles each user has are stored as XML in a
> database and may be configured by an administrator. Does struts have any
> built-in security capabilities that I could take advantage of?
>
>
> Any help/pointers would be much appreciated!
>
> My first guess would be to put all jsp pages in WEB-INF (use only
> ForwardAction to get to each page) and subclass ActionServlet with the logic
> for check authentication etc. However, will this cause any problems when it
> comes to a user book marking a page?
>
> Thanks,
> -Ryan Cuprak
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
