Hi Take a look at SecurityFilter - http://securityfilter.sourceforge.net/
Works like a charm with Tomcat and JDBC realms. Then you do REAL declarative security - No coding needed. Hermod -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, January 27, 2005 6:31 AM To: user@struts.apache.org Subject: RE: Struts Security I think the logic:present tag will allow access to any of the roles mentioned. Mohan -----Original Message----- From: Tim Christopher [mailto:[EMAIL PROTECTED] Sent: Thursday, January 27, 2005 9:41 AM To: Struts Users Mailing List Subject: Re: Struts Security 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] This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that the DnB NOR Group cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
