Ron, You can associate roles with each action mapping so that only users with certain roles can access that action.
<action path="/admin" type="com.company.action.AdminAction" roles="administrator"/> Hubert --- ron1 <[EMAIL PROTECTED]> wrote: > Thanx Jim :-) > Am I wrong on that one canonly configure web.xml roles on a servlet > base? which will mean, I set roles for a servlet mapping? so all my > struts actions will map to the same Permission... > Or did I miss something in the web.xml? > Cheers, > Ron > > > > Jim Barrows wrote: > > > >>-----Original Message----- > >>From: news [mailto:[EMAIL PROTECTED] Behalf Of ron1 > >>Sent: Thursday, July 15, 2004 11:51 AM > >>To: [EMAIL PROTECTED] > >>Subject: How to use roles with Struts > >> > >> > >>Hi all :-) > >>I am wondering how some of the experienced users use roles > >>with struts. > >>I saw there is a query for roles in the API (getRoles()), but > >>could not > >>figure out how to configure ACLs with struts, or more > >>specific: where to > >>define which action is allowed for which role, and, and I > >>guess that is > >>done through Java, how to set the user's role in, for > >>example, after ge > >>logs in. > >> > >>My application will use 3 roles, and perhaps an additional admin role: > >>some actions / pages will have unlimited access ( guest or visitor) > >>some others will need a log in (user) > >>and some others will need a privelege (priveleged user). > >> > >>Could you share your experience? > > > > > > 2 approaches, the declartive security that is part of web.xml or roll > your own. > > > > With roll your own there are two approaches: > > 1) A base action the checks roles and other authorization before doing > anything, and your other > > actions inherit from that. (or you can just hard code the authorization > check in each class) > > 2) Use Filters. > > > > I like using filters for applications that must be secure, since I can > choose a default deny approach, rather then the more permissive default > allow that the declaritive security provides. In addition, as your access > rules and authorization methodologies change, you can change with them > without having to wait for your server to change too...... > > > > On the other hand for a public side website, I prefer the web.xml version > because I'm lazy and don't want to think about security for the most part. > The public side is usually better to have default allow becasue you want > most people to view the entire site. Its easier to specify what to protect > then what to allow in such cases. > > > > > >>What I currently imagine as to be a good solution is a Permission > >>setting on the action configuration (e.g. at struts-config.xml) which > >>will be automatically checked at the controller instance, and forward > >>users to login / not permitted pages. > >> > >>Cheers and thanx advance, > >>Ron > >> > >> > >>--------------------------------------------------------------------- > >>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] > > __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
