schaloner/deadbolt

Authorisation module for the Play! framework

deadbolt's Issues

Not possible to restrict authentication to just methods with authorisation restrictions

I have a Play v1.2.5 app that integrates DeadBolt with SecureSocial. I would like to just authorise a specific method so I've annotated the controller with @with(Deadbolt.class) and the specific method with @RoleHolderPresent.

The problem is that in Deadbolt.checkRestrictions(), the call to DEADBOLT_HANDLER.beforeRoleCheck(), which calls back into SecureSocial to authenticate the user, is done before the call to getRestrictionType() which means that authentication is required for methods that are not restricted.

It seems like this could be resolved by swapping the order of these two calls so that the check for a restriction takes place first and then if there is a restriction then to check for an authenticated user, e.g.:

    RestrictionType restrictionType = getRestrictionType();

    if (restrictionType != null && restrictionType != RestrictionType.NONE) {
        DEADBOLT_HANDLER.beforeRoleCheck();

        RoleHolder roleHolder = getRoleHolder();

        if (restrictionType == RestrictionType.DYNAMIC)
        {
            handleDynamicChecks(roleHolder);
        }
        else if (restrictionType == RestrictionType.STATIC)
        {
            handleStaticChecks(roleHolder);
        }
        else if (restrictionType == RestrictionType.BASIC)
        {
            handleRoleHolderPresent(roleHolder);
        }
    }

Can you see a problem with this?

cheers,
Chris

Support for Play 2.0

Is there any support planned for play 2.0?

Overriding and relaxing class restrictions at the method level

I have a class restriction of 'admin' but I'd like to relax some of the methods in that class for RoleHolderPresent. Is this possible or even desirable?

Mysterious exception using deadbolt.restrict tag

I've got a mysterious exception with the deadbold.restrict tag. It seemed to work when I had an authenticated user that had the 'admin' role but once I had signed out the following exception occurs when I try to access that page. I wonder if this could be related to the fact that I'm using Faster Groovy Templates. The tag itself looks fine and the stack trace unfortunately doesn't allude to what is causing the redirect.

    #{deadbolt.restrict roles:[['admin']]}
    #{a @CRUD.index()}Admin#{/a}
    #{/deadbolt.restrict}

15:29:18,326 [play-thread-1] ERROR ~

@6afp74nce
Internal Server Error (500) for request GET /

Template execution error (In {module:deadbolt-1.5.3}/app/views/tags/deadbolt/restrict.html around line 1)
Execution error occured in template {module:deadbolt-1.5.3}/app/views/tags/deadbolt/restrict.html. Exception raised was Redirect : null.

play.exceptions.TemplateExecutionException
at play.modules.gtengineplugin.GTTemplate.renderGTTemplate(GTTemplate.java:111)
at play.modules.gtengineplugin.GTTemplate.internalGTRender(GTTemplate.java:75)
at play.modules.gtengineplugin.GTTemplate.internalRender(GTTemplate.java:54)
at play.modules.gtengineplugin.GTTemplate.render(GTTemplate.java:128)
at play.mvc.results.RenderTemplate.(RenderTemplate.java:24)
at play.mvc.Controller.renderTemplate(Controller.java:660)
at play.mvc.Controller.renderTemplate(Controller.java:640)
at play.mvc.Controller.render(Controller.java:695)
at controllers.Home.index(Home.java:62)
at play.mvc.ActionInvoker.invokeWithContinuation(ActionInvoker.java:548)
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:502)
at play.mvc.ActionInvoker.invokeControllerMethod(ActionInvoker.java:478)
at play.mvc.ActionInvoker.invokeControllerMethod(ActionInvoker.java:473)
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:161)
at Invocation.HTTP Request(Play!)
Caused by: play.mvc.results.Redirect
at {module:deadbolt-1.5.3}/app/views/tags/deadbolt/restrict.html.(line:1)
at play.template2.GTJavaBase.internalRenderTemplate(GTJavaBase.java:124)
at play.modules.gtengineplugin.gt_integration.GTJavaBase1xImpl.internalRenderTemplate(GTJavaBase1xImpl.java:82)
at play.template2.GTJavaBase.invokeTagFile(GTJavaBase.java:252)
at /app/views/uis/SignOut.html.(line:13)
at play.template2.GTJavaBase.internalRenderTemplate(GTJavaBase.java:124)
at play.modules.gtengineplugin.gt_integration.GTJavaBase1xImpl.internalRenderTemplate(GTJavaBase1xImpl.java:82)
at play.template2.compile.GTInternalFastTags.tag_include(GTInternalFastTags.java:118)
at /app/views/Home/index.html.(line:62)
at play.template2.compile.GTInternalFastTags.tag_set(GTInternalFastTags.java:64)
at play.template2.GTJavaBase.internalRenderTemplate(GTJavaBase.java:124)
at play.modules.gtengineplugin.gt_integration.GTJavaBase1xImpl.internalRenderTemplate(GTJavaBase1xImpl.java:82)
at play.template2.GTJavaBase.renderTemplate(GTJavaBase.java:97)
at play.modules.gtengineplugin.GTTemplate.renderGTTemplate(GTTemplate.java:93)
... 14 more

[1.4.4] Bug in the doc page

Hi,

When reading :
http://www.playframework.org/modules/deadbolt-1.4.4/home#Unrestricted

// This unrestricts access to the Foo controller, even if the parent controller is restricted.
@RoleHolderPresent
public class Foo extends Controller

I think it's a copy/paste bug and it would be the annotation "Unrestricted "

Regards

Instead of Restrict

Doesn't it make more sense to list what roles can access a give method? It seems more complex to list which ones can not and less intuitive. Am I mis-reading here or something? What is the logic for this?

Use deadbolt for implementing ACL (read-only) like user groups

Hi,

First of all, I am not sure if this is the right place for feature request or other issues that bug reporting. Please excuse me if I should have this kind of design discussion in the Play group discussion.

My intention is to implement ACL control in Play Framework. My idea or requirement is to allow users to define user groups by names, which can contain user members, similar to the Role concept in Deadbolt. For models owned/created by a user (e.g. a photo or blog entry), the user can assign certain rights (read-only), for example, group names, which members can have read-right to the model.

I guess the deadbolt is quite capable of adding restriction on model/controller/view levels. I just need to hear from your opinions and study your code more, if it's feasible.

Thanks.

Regards,
Yu

Logging error

Within Deadbolt.checkRestrictedResource() method, it is logging an incorrect message when access has been denied. The case default: statement will only trigger for DENIED cases, yet debug message states "access allowed".

            switch (accessResult)
            {
                case ALLOWED:
                    ...
                    break;
                case NOT_SPECIFIED:
                    ...
                    break;
                default:
                    // <- Incorrect message
                    Logger.debug("RestrictedResource - access allowed for [%s]",
                                 resourceKeys);
            }