grails plugin - annotations

[Bradley Beddoes-2]

Hi Gang,
I tried this message over on grails-users a few days back but no one seems to have any ideas, hoping I might get a hit here with some grails jsecurity plugin users.

I am attempting to test RoleRequired annotation on a *very* basic controller defined as such:

import org.jsecurity.grails.annotation.RoleRequired

class EntityController {
   
    @RoleRequired('nosuchrole')
    def list = {
        [entities : EntityDescriptor.list() ]
    }
}

As you'd imagine I expect execution of the controller to not be allowed as no user has the role 'nosuchrole'. I can confirm that my setup in SecurityFilter.groovy does require the user to authenticate and that the closure is executed. Not seeing any immediate logging output.

Any ideas as to what I am doing wrong would be appreciated, probably something minor I have overlooked.

regards,
Bradley

[Les Hazlewood-2]

Hi Bradley,

Annotations are enabled in Spring environments using Spring-specific
XML declarations in applicationContext.xml.

There is a Spring sample application in JSecurity that shows how this
is enabled - you might want to play with it a bit.

Here is the relevant config:

<!-- Enable JSecurity Annotations for Spring-configured beans.  Only run after
         the lifecycleBeanProcessor has run: -->
    <bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"
          depends-on="lifecycleBeanPostProcessor"/>
    <bean class="org.jsecurity.spring.security.interceptor.AuthorizationAttributeSourceAdvisor">
        <property name="securityManager" ref="securityManager"/>
    </bean>

Peter, does the Grails plugin not enable this automatically?

Cheers,

Les

On Thu, Nov 13, 2008 at 8:22 AM, Bradley Beddoes
<[hidden email]> wrote:

> Hi Gang,
> I tried this message over on grails-users a few days back but no one seems
> to have any ideas, hoping I might get a hit here with some grails jsecurity
> plugin users.
>
> I am attempting to test RoleRequired annotation on a *very* basic controller
> defined as such:
>
> import org.jsecurity.grails.annotation.RoleRequired
>
> class EntityController {
>
>     @RoleRequired('nosuchrole')
>     def list = {
>         [entities : EntityDescriptor.list() ]
>     }
> }
>
> As you'd imagine I expect execution of the controller to not be allowed as
> no user has the role 'nosuchrole'. I can confirm that my setup in
> SecurityFilter.groovy does require the user to authenticate and that the
> closure is executed. Not seeing any immediate logging output.
>
> Any ideas as to what I am doing wrong would be appreciated, probably
> something minor I have overlooked.
>
> regards,
> Bradley

[pledbrook]

> Peter, does the Grails plugin not enable this automatically?

The annotation that Bradley is talking about is handled by the plugin
itself. The truth is, I haven't touched the annotation stuff in a long
time, so I can barely remember how it works, let alone what to do to
enable them :)

Having said that, I've just had an idea. Bradley, could you try adding
this option to you Config.groovy file:

  jsecurity.legacy.filter.enabled = true

? That may do what you need.

Hope that helps,

Peter

[Jeremy Haile]

Peter - can you explain a little more about what that property does?  
Any downside to enabling it?

On Nov 13, 2008, at 10:31 AM, Peter Ledbrook wrote:

>> Peter, does the Grails plugin not enable this automatically?
>
> The annotation that Bradley is talking about is handled by the plugin
> itself. The truth is, I haven't touched the annotation stuff in a long
> time, so I can barely remember how it works, let alone what to do to
> enable them :)
>
> Having said that, I've just had an idea. Bradley, could you try adding
> this option to you Config.groovy file:
>
>  jsecurity.legacy.filter.enabled = true
>
> ? That may do what you need.
>
> Hope that helps,
>
> Peter

[pledbrook]

> 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

[Bradley Beddoes-2]

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 <[hidden email]> 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

[pledbrook]

> Enabling the legacy filter as described makes everything play as you would
> expect and I now get denied access to that controller/action.

Good to hear!

> 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?.

To be honest I had forgotten about the annotations - the
"beforeInterceptor" approach was the main target of deprecation. I
think this is a perfectly valid approach, so it would be nice if they
worked by default. One thing I can't remember is why I wrote custom
annotations rather than using the core JSecurity ones. Ah, I remember
now (having quickly looked at the code): the JSecurity annotations
only apply to methods, but I needed them to apply to fields too,
because that is what Grails controller actions are.

I don't know what the other guys think, but it may be worth modifying
the JSecurity annotations so that they can be applied to fields.
However, that may require code changes in other parts of the code to
ignore annotations on fields.

Cheers,

Peter