On Tue, 30 Jul 2002, Jacob Hookom wrote:
> Date: Tue, 30 Jul 2002 21:35:00 -0500
> From: Jacob Hookom <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> Subject: RE: Security and Struts
>
> I think the real issue is that realm authentication and filter
> authentication is context based. Aside from messing with tiles (great
> technology, just not interested) what is pro quo for pageContext
> security if I use the same view for multiple items?
>
> IE, you can see page.jsp?id=3 but not page.jsp?id=4
>
Data-level security (i.e. you can access only part of the customers table,
not the whole thing) is generally handled at the EJB layer if you're using
it. At the web layer, one approach would be to have a coarse-grained role
(assigned to a user) that gave him or her access to the page, and then
finer grained roles for access to various subsets of data. Then, in the
page itself, you can use request.isUserInRole() -- or the equivalent
<logic:present role="..."> check -- to display the data (if they can see
it) or some polite error message (if they cannot).
> Jacob Hookom
> Comprehensive Computer Science
> University of Wisconsin, Eau Claire
>
Craig
>
> -----Original Message-----
> From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 30, 2002 8:32 PM
> To: Struts Users Mailing List
> Subject: Re: Security and Struts
>
> Troy Hart wrote:
>
> >I don't think it is that much work to put an action in front of every
> >jsp page that represents "page" in your application. I actually think
> it
> >is a very good abstraction.
> >
> o.a.s.actions.ForwardAction works *really well* (and simply) for this -
> as does the NoOpAction (for fowarding to definitions - can't forget
> Tiles!).
>
> >A couple of the advantages I can think of
> >right now include:
> >
> >1) It gives your web-app a stable interface and simultaneously allows
> >you to freely swap the actual response generating resource, behind the
> >scenes. You provide a action mapping where you tie a stable name to an
> >action class, or even some other arbitrary resource...whatever suits
> >you. Along with this approach, most people will hide the jsp in
> WEB-INF.
> >I've heard reports of some having troubles with the hiding part, but it
> >has worked well for me.
> >
> >2) You can sleep well at night knowing that all requests go through
> your
> >special request processing logic...you won't have to worry about the
> >"secure" page that you forgot to include the special taglib on. This
> >need can arguably be mitigated by using cma/filters.
> >
> No argument ;-) It *can*! (forget the filters - let the container do
> it!)
>
> Peace :-)
>
> Eddie
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.380 / Virus Database: 213 - Release Date: 7/24/2002
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.380 / Virus Database: 213 - Release Date: 7/24/2002
>
>
>
> --
> 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]>
