For all my pages, I looked at the site as layers, and each page in each
layer has a unique ID, so it may be /companyProduct.jsp?cpID=3399
In my database, I have two tables (basic):
1. Layer Hierarchy View
Maps the Heirarchy of the Business Objects
Company->Division->Product
This allows me to lookup any level to see its parent level
2. Security Table
Maps user id's to a level and a leveled
In the case above, the product may be level 4, and the id would
be 3399
To supplement these tables, I wrote stored procedures that recursively
walk up the hierarchy checking permissions, so if a permission entry was
not at the product level for a user, the stored procedure looks up the
parent of the product, subtracts one from the level and searches the
security table for a matching row at the division level with the
product's parent ID.
view_Heirarchy
comComID coName divDivID divName proProID proName
56 Acme Corp 445 Dynamite 3399
m80
tbl_Security
secSecID secLevel secLevelId secUsrID
4990 2 445 3
So if user 3 requested the product 'm80', the stored procedure would
look up tbl_security for level 3, levelId 3399, and userId 3. Since
it's not there, it finds the parent level (division 445) and does a
check for level 2, levelId 445, and userId 3. It finds it so it returns
true and stores that true state in the user's session so next time the
user requests m80's, it's just a matter of doing a
list.contains(object);
It's worked nice for me since I can then do boolean tags on my pages
that say:
<dds:admin level="3" parameter="cpId">
//display modify material
</dds:admin>
-or-
// security exception
<dds:notadmin level="3" parameter="cpId">
<jsp:forward page="errors/401.html"/>
</dds:notadmin>
Hopes this gives you some ideas...
Jacob Hookom
Comprehensive Computer Science
University of Wisconsin, Eau Claire
-----Original Message-----
From: David Graham [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 30, 2002 5:03 PM
To: [EMAIL PROTECTED]
Subject: RE: Security and Struts
I've done it by using a custom tag on all the secured pages that checks
the
login but this isn't ideal. I could forget to put the tag in and I have
to
do it for every page.
If you let struts do it then you can't let people go to .jsp pages
directly
and I find this irritating at best.
Should you only use struts for the webforms and not for public display
pages? I've always been a bit confused by this. It seems that struts
was
designed for the forms stuff but not necessarily to sit in front of your
whole app.
Thanks,
Dave
>I tend to think the action is the wrong place for this sort of thing. I
>could be wrong but that's just how it occurs to me. It seems that this
>should either be handled in front of your web application (using
>cma/filters) or by the front controller components in the struts
>framework (NOTE: requests that do not map to the controller servlet,
>like requests directly to a jsp page, will not invoke your request
>processing logic).
>
>Struts also helps you along here. It provides a way for you to
>*declare*, along with each action mapping (in struts-config.xml), a
>specific set of roles that have access to the given action. Then, the
>RequestProcessor defines the method processRoles() that you are free to
>override, but by default it will invoke:
>
>request.isUserInRole(someRole)
>
>for each role declared in the action mapping. If the user is found to
be
>included in any of the roles then processRoles() returns true,
otherwise
>it returns false. True is also returned in the case where no roles are
>declared on the action mapping. Check out the struts source for more
>detail...
>
>Unless you use the cma/filters approach (and I haven't, so I don't know
>what the issues are there), there will still be some details for you to
>work out with respect to getting an authenticated user into the
session.
>This could be handled in a number of different ways. One that occurs to
>me, off the top of my head, would be to wire a login page into the page
>that is forwarded when processRoles() returns false...
>
>There may be some mis-truths in what I have said here, I am currently
>working through some of this stuff, but in general I think the idea is
>sound. Certainly having declarative security is something that you
>should strive for...
>
>If anyone has feedback on what I've said here, I would love to hear it!
>
>Thanks & Good Luck,
>
>Troy
>
>
>On Tue, 2002-07-30 at 12:59, Nelson, Tracy (ETW) wrote:
> > I'd have each form check authorization. That way, if someone
bookmarks
>a
> > page (or guesses its URL) they won't bypass your security scheme.
You
>could
> > have a global exception set up in your configuration file that
forwards
>to
> > an "Access denied" page whenever one of your forms threw a
>UserNotAuthorized
> > exception. (NOTE: I am just learning Struts and haven't even
written my
> > first application using it yet. I may not know what I am talking
>about.)
> >
> > Cheers!
> > -- Tracy
> >
> > -----Original Message-----
> > From: Ryan Cuprak [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, July 30, 2002 11:53
> > 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]>
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
--
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]>
