1

I'm migrating an existing Java Play 2.5 application to Scala and found in the view main.scala.html the use of the following deadbolt-2 class subjectPresentOr:

@subjectPresentOr() {
  <ul class="nav navbar-nav navbar-right">
    @defining(userProvider.getUser(session())) { user =>
    ... user is present html
    }
} {
  ... user is NOT present html    
}

After migrating all controllers and actions to Scala (and changing the deadbolt-2 dependency from Java -> Scala) I get the following compiler error due to the fact that subjectPresentOr requires an implicit request of type AuthenticatedRequest[Any]:

main.scala.html:49: could not find implicit value for parameter request: 
    be.objectify.deadbolt.scala.AuthenticatedRequest[Any]

and I have some intuition why ... some times e.g. when the user is not yet logged in there is no request of type deadbolt-2's AuthenticatedRequest[_] but the superclass type play.api.mvc.RequestHeader and it can't be rightfully so implicitly matched with its subclass AuthenticatedRequest[_].

The question is why this works in the Java version in the first place? The Java version of @subjectPresentOr doesn't require any implicit request :)

To fix it in the Scala version I would wrap the @subjectPresentOr block with pattern matching to discover the dynamic type of the implicit request and only if its dynamic type is AuthenticatedRequest[_] I will then show the block and pass to @subjectPresentOr explicitly the narrowed request of that type. This is not super elegant though but I can't figure any other way ...

SkyWalker
  • 13,729
  • 18
  • 91
  • 187

1 Answers1

1

The Java version of Play has a Http.Context available to it via ThreadLocals, whereas the Scala version uses requests. These may be implicit or explicit.

Looking at your controllers, when you add Deadbolt to an action you will receive an AuthenticatedRequest. So, a non-Deadbolt action of 

def foo = Action { request =>
  // request is of type Request
}

would receive a request of type Request, whereas the same action protected by Deadbolt

def foo = actionBuilder.SubjectPresentAction().defaultHandler() { request =>
  // request is of type AuthenticatedRequest
}

receives a request of type AuthenticatedRequest.

If you want to convert a Request to an AuthenticatedRequest because you're calling a template that contains Deadbolt constraints yet your controller action is unconstrained, you can use WithAuthRequestAction:

def foo = actionBuilder.WithAuthRequestAction().defaultHandler() { request =>
  // request is of type AuthenticatedRequest
}

If you're injecting DeadboltActions in place of ActionBuilders, the same holds true:

def foo= deadboltActions.SubjectPresent()() { request =>
  // request is of type AuthenticatedRequest
}

You can also just create an instance of AuthenticatedRequest from the existing Request and with no Subject by using new AuthenticatedRequest(request, None).

Steve Chaloner
  • 8,162
  • 1
  • 22
  • 38
  • @(Steve Chalonder) Thank you, yes it all makes sense. I think the problem is solved using `actionBuilder.WithAuthRequestAction().defaultHandler()` in every action that returns `RequestHeader`. btw is this a shorter version: `actionBuilder.WithAuthRequestAction()()` ? again thank you for the help and for the very clean code of Deadbolt-2, Play should learn from it e.g. regarding the clean design separating Java from Scala instead of their confusing `play.x` vs `play.api.x`. – SkyWalker Dec 16 '16 at 09:04
  • [ActionBuilders](https://github.com/schaloner/deadbolt-2-scala/blob/master/code/app/be/objectify/deadbolt/scala/ActionBuilders.scala) provides a alternative syntax for [DeadboltActions](https://github.com/schaloner/deadbolt-2-scala/blob/master/code/app/be/objectify/deadbolt/scala/DeadboltActions.scala) so `actionBuilder.WithAuthRequestAction()()` isn't valid. See https://deadbolt-scala.readme.io/docs/action-builders and https://deadbolt-scala.readme.io/docs/action-composition for further details. – Steve Chaloner Dec 16 '16 at 09:13