Hi, I've never used EJB so have no idea what this means, can someone explain please?
"When SecurityFilter is used, a user's Principal will not automatically be propagated to EJB calls. If this is a requirement for your application, you may not be able to use SecurityFilter." Also, (as above) I'm using JDBCRealm to authenticate clients. I then have a tile which contains all the menu settings; I use the present roles to check for which features should be loaded.... How easy would it be to implement this using the SecurityFilter - does anyone know of a good tutorial? Cheers, Tim On Thu, 27 Jan 2005 08:25:14 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
