rey--
that seems like a reasonable approach, but i've read in more than one post on
this board that subclassing the ActionServlet should be avoided. wouldn't it be
better to put this code directly into the action servlet and rebuild struts?
i'd also be interested in hearing the rationale behind the desire not to
subclass ActionServlet from those of you who prefer to avoid it.
jon
Rey Francois wrote:
> We actually do more or less the same. During the login phase we retrieve the
> user profile which includes the authorization information and store this in
> the session context. Each action can then take some access control decision
> based on this information.
>
> However I am currently trying to use JAAS (Java Authentication and
> Authorization Service) just for the authorization part. I have written a doc
> on the various issues of doing so and how I'm planning to do so. I'm still
> working on it but it may be useful to some of you, so I attach it. This
> document mentions "eShell": this is the name of the framework we use, and it
> is extending Struts.
>
> As usual, any comments on this is welcome :)
>
> Fr.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 24 August 2001 15:27
> To: [EMAIL PROTECTED]
> Subject: RE: Security, authentication and authorisation with Struts
>
> > I wondered what approach you guys took when implementing security,
> > authentication and authorisation. I have the common scenario
> > where the application I am creating allocates roles to certain
> > types of users, allows them to login, then restricts access to
> > certain pages and within the pages certain content.
>
> I use a subclass of ActionServlet that ensures that the username
> (a String) and authorization info (a bean) for this user are
> saved in the session scope before any Actions are called. (They
> aren't combined into one object because I need the username
> for other situations when I may not require auth information.)
>
> At the top of each Action I consult the authorization bean to see
> if this user has the appropriate permissions to call this Action.
> If so, I just keep going. If not, I forward to a JSP that tells
> them "no". If the authorization bean doesn't exist anymore it's
> because the session timed out in which case I forward to another
> JSP asking them to start over. The ability to choose your view in
> the Action is really, really nice.
>
> I don't have a login procedure because there is a front-end that
> they need to pass through before they get to my application
> and this guarentees me a username in the HTTP headers. So I just
> need to pull it out of the headers in the special ActionServlet
> subclass and put it in the scope. But it would be easy enough for
> a login page to do the same thing.
>
> Devon
>
> ************************************************************************
> The information in this email is confidential and is intended solely
> for the addressee(s).
> Access to this email by anyone else is unauthorised. If you are not
> an intended recipient, you must not read, use or disseminate the
> information contained in the email.
> Any views expressed in this message are those of the individual
> sender, except where the sender specifically states them to be
> the views of Capco.
>
> http://www.capco.com
> ***********************************************************************
>
> ------------------------------------------------------------------------
> Name: JAAS and eShell.html
> JAAS and eShell.html Type: Hypertext Markup Language (text/html)
> Encoding: quoted-printable
