Joe, I tried it on a demo ages ago so I thought I'd pass it along. After rewiewing the site, I see what you mean.
Regards, David -----Original Message----- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 07, 2004 11:33 AM To: David G. Friedman; Struts Users Mailing List; Dahnke, Eric (Company IT) Subject: RE: Flexible ACLs using Struts At 7:48 PM -0500 12/6/04, David G. Friedman wrote: >How about Pow2ACL? >http://pow2acl.sourceforge.net/ David, have you used pow2acl? I like the idea of a good shared ACL library, but I see some potential issues, at least with their Struts integration. First, from the website, it appears that they haven't caught up with even Struts 1.1, as they have an ActionServlet implementation which overrides processActionPerform, which was moved into RequestProcessor almost two years ago. Still, it does provide a general API which could probably be adapted to the purpose, and they mention a web UI for some administration purposes. Still, I think it would be better to implement the access check in the request processor rather than requiring you to use up your single inheritance extending from an action which provides that functionality. Joe >Regards, >David > >-----Original Message----- >From: Joe Germuska [mailto:[EMAIL PROTECTED] >Sent: Monday, December 06, 2004 5:46 PM >To: Dahnke, Eric (Company IT); Struts Users Mailing List >Subject: Re: Flexible ACLs using Struts > > >Assuming you can define an interface (like "AccessControlManager") >and instantiate an implementation of the instance at servlet init >time (using ServletContextListener or PlugIn), it should be pretty >straightforward. > >In the RequestProcessor you'd use the reference to the servlet to >retrieve your manager. Then you'd fish out of the request or session >whatever you know about the current user and client, and some config >information from the ActionMapping like the path. Then you hand all >these things a method on your AccessControlManager which evaluates >the rules and tells you whether you should let them continue or not. > >Is your problem figuring out how to pass in the necessary config >information for the action? How do you model it? If you don't want >per-path rules, then use the "parameter" property to pass in an >"action-group" code or something, or if you need more config >properties, extend ActionMapping and use the struts-config to set >arbitrary bean properties. > >Or is your problem figuring out how to deal with access denied >scenarios? I could see where Struts' configuration options make that >kind of cumbersome, since the API of RequestProcessor kind of assumes >you've dealt with the response inside processRoles. The >struts-chain code under development would make it easier for you to >do more than just requestDispatcher.forward(...) from inside >processRoles... > >Does any of this help? > >Joe > > > >At 5:06 PM -0500 12/6/04, Dahnke, Eric (Company IT) wrote: >>Hello, For a few Struts apps in a row now, we've used the roles >>attribute and an overriden processRoles() method in a custom request >>processor to handle access control within struts apps. A user's Roles >>are gotten from the database at login and stored in the User object in >>the session. The User object has a hasRole() method that compares the >>user's roles to those that arrive in the ActionMapping, and the >>processRoles() method returns an ActionForward of "NotAuthorized" if >>there is no match. >> >>I'm working on a new application, that needs configurable ACLs. For >>example, one client may choose to allow users of a certain role perform >>action X, other clients may not. There are 20 or 30 of these types of >>flexible actions. >> >>Has anyone come up with a pragmatic way to implement flexible ACLs using >>Struts? Essentially, I need one Role to many Actions functionality, as >>where the roles="" attribute of struts-config gives me the opposite? >>Thx! >>-------------------------------------------------------- >> >>NOTICE: If received in error, please destroy and notify sender. >>Sender does not waive confidentiality or privilege, and use is >>prohibited. >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > >-- >Joe Germuska >[EMAIL PROTECTED] >http://blog.germuska.com >"Narrow minds are weapons made for mass destruction" -The Ex > >--------------------------------------------------------------------- >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] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
