Just a quick question... What is gained by using code like this:
>>>
String[] roles = mapping.getRoleNames();
if(roles == null || roles.length == 0)
return true
for(int i=0; i<roles.length; i++) {
if(request.isUserInRole(roles[i])) {
return true;
}
}
return false;
<<<
...isn't that the same as <logic:present role="roleA, roleB, roleG">?
Or is that a check for all roles: roleA, roleB, and roleG?
Tim
On Wed, 26 Jan 2005 20:27:22 -0700, Nic Holbrook <[EMAIL PROTECTED]> wrote:
> I forgot to mention the reason I did this was because we already had a
> security mechanism in place and didn't have the liberty of using realms
> on the web or anything like that. It had to be a custom configuration.
>
> Nic Holbrook wrote:
>
> > I kind of set our security up before the struts menu was in place.
> > What I have done that seems to work well so far is extend the Action
> > class with a SecureAction class that validates the users role before
> > it lets the user into an action. The execute method actually
> > validates and calls an abstract secureExecute (which is now the main
> > struts method) if the user is in the role. I set a roleId in the
> > struts-config.xml for each action which really isn't a big deal
> > (<set-property property="actionRole" value="700"/>). That way the
> > role is set up 1 time for each action. You can use the same role for
> > several actions of you like. When the user logs in, I retrieve all
> > the roles allowed for that user and store it in a UserContext object
> > in the session. I then have a menu tag that dynamically builds the
> > menu for them which isn't that difficult to set up. I use it in a
> > tile so I only insert it 1 time.
> >
> > Just some ideas.
> >
> >
> >
> > Craig McClanahan wrote:
> >
> >> On Sun, 23 Jan 2005 18:39:50 +0000, Tim Christopher
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>> Hi,
> >>>
> >>> I am designing a web application using Struts, which will run using
> >>> Tomcat. The system will have upwards of 1000 users, with each user
> >>> having any number of around 10 possible roles.
> >>>
> >>> I'm currently thinking of using JDBCRealm within the Tomcat xml file
> >>> to set the roles for each of the users, then extending the
> >>> RequestProcessor to ensure only authorised users can enter the secure
> >>> area. I then have a number of menu options that should only be made
> >>> visible to users with certain roles; I intend to use logic:present
> >>> role=".." or req:isUserInRole role="..." to do this - from what I can
> >>> see they are functionally identical(?).
> >>>
> >>>
> >>
> >>
> >> The implementation of logic:present role= uses request.isUserInRole()
> >> under the covers :-).
> >>
> >>
> >>
> >>> I guess what I'd like to know is:
> >>> * Will this approach actually work?
> >>>
> >>
> >>
> >> Yep.
> >>
> >>
> >>
> >>> * Is there a better way?
> >>>
> >>
> >>
> >> This sounds best for your use case.
> >>
> >>
> >>
> >>> * Will any changes to user roles made within the database
> >>> automatically update the roles that tomcat uses from the JDBCRealm, or
> >>> will it require a server restart?
> >>>
> >>
> >>
> >> Tomcat's JDBCRealm caches the relevant roles for a user when he or she
> >> logs on, so they won't change for the length of that session ... but
> >> changes will get reflected next time the same person logs on.
> >>
> >>
> >>
> >>> * Also if I use a check within the jsp like logic:present role=".."
> >>> to decide if a component should be dispalyed, I have read it is also
> >>> advisable to require to presence of a role to use the Action. This
> >>> method will require two updates to allow an additional an additional
> >>> role to access a resource (update in the jsp, and in the xml file) -
> >>> is there a way around this?
> >>>
> >>
> >>
> >> You can prohibit direct access to JSP pages (requiring that they go
> >> through an Action first) and only need to configure the XML file to
> >> limit access to a complete page. But you'll still need the inner
> >> logic if you want to do things differently, based on role, within a
> >> page.
> >>
> >>
> >>
> >>> Thank you in advance,
> >>>
> >>> Tim Christopher
> >>>
> >>>
> >>
> >>
> >> Craig
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
