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]
