Ben, Thanks for your response.
This is certainly not a big problem, I see some minor advatages to attaching the security to the bean or the controller in question but these are not big enough advantages to warrent a large development effort. If I find, during the course of my project, that the advantages are bigger than they currently seem then I will certainly develop the classes required to support this method and submit them. Once again, thanks for your time. Wesley P.S. Notice the lack of a 't' in that spelling ;o) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ben Alex Sent: 19 July 2004 04:16 To: [EMAIL PROTECTED] Subject: Re: [Acegisecurity-developer] Assigning roles to URL's and MethodInvocations Hi Westley Wesley Hall wrote: >Lets take the example of URL based security (The >FilterInvocationInterceptor). The mapping between the security role required >and the actual code that handles that URL invocation seems to be based on a >list of URL's and the roles required to access them. I can understand the >benefits of this approach but I have found that if I decide to change my >controller mappings I also have to go back and change the information >supplied to the objectDefinitionSource attribute of the >FilterInvocationInterceptor. > >I wonder whether it would be possible to obtain the information provided by >the objectDefinitionSource from the Controller itself. > >Lets say I have a controller called 'AdminController' that provides the >model and the view for a system administration screen. This controller is >mapped to /admin/index.html. The objectDefinitionSource in the >FilterInvocationInterceptor has '\A/admin/.*\Z=ROLE_ADMIN'. If I later >decide that the admin URL shoudl be '/tools/admin.html' I have to change >both the controller mapping and the objectDefinitionSource. > >This is not a major problem, and perhaps I am splitting hairs but if the >'ROLE_ADMIN' was assigned directly to the controller then I could remap URLs >without needing to reconfigure the security system. > > > The current approach is based on the Servlet spec. I felt it was a reasonable basis because people are already familiar with how it works, and providing it via Acegi Security frees people from needing container security via web.xml. The implementation also provides web framework independence, as I know we have users utilising a range of web frameworks. AFAIK, there is nothing preventing anyone from writing a new class that behaves the way you describe. It's just a question of priorities. Nobody has felt strongly enough about the potential maintenance issue to go write one. And I guess the alternative - web.xml security constraints - would require the same (or probably more, due to the inflexible path mappings) maintenance. >I suspect that a similar approch could be used to wrap the 'BankManager' >bean in your provided example, this would allow the security information to >remain 'attached' to the object that it is securing. > > > The MethodSecurityInterceptor approach was based on Spring's own transaction definition approach.Once again, so people migrating would recognise it and feel comfortable. As an aside, some people feel Acegi Security is too complex. This is probably because it has somewhat deep documentation, covering all of its pluggable points, and a lot of bean definitions, so you can utilise all of that pluggable support. In its most commonly used form, the two security areas (URL and method interception) are configured just like official Servlet spec or Spring standards. As always, I welcome any patches which improve the project. Best regards Ben ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
