Hi All, Thanks for your valuable feedback. Enabling the legacy filter as described makes everything play as you would expect and I now get denied access to that controller/action.
>From the discussion above it seems that the annotation approach has been deprecated in favor of filters (which I am also using). If this is the preferred way forward then no worries, if it still has some use I may be able to find some time at some point to try and port it over to the current plugin codebase by default - thoughts?. regards, Bradley On Fri, Nov 14, 2008 at 1:58 AM, Peter Ledbrook <[EMAIL PROTECTED]>wrote: > > Peter - can you explain a little more about what that property does? Any > > downside to enabling it? > > It enables a Grails filter that mimics the old behaviour of the > plugin. Back in the 0.1.x days, the access control configuration was > specified in the controllers themselves. Since then, the preferred > approach is to define access control in your own Grails filters (which > are Spring HandlerInterceptors under the hood), so I deprecated the > old controller-centric approach. > > There's no real downside to enabling the legacy filter other than it > executes on every request to a controller. So if you're not using it, > there's no point enabling it. I doubt the performance penalty is > significant, but in truth I have never tested it. > > Cheers, > > Peter >
