0

I am using Deadbolt2 for authorization. When i, extends DeadboltHandler and override their methods, i am getting following error in eclipse: 

implements be.objectify.deadbolt.scala.DeadboltHandler.getSubject
overriding method getSubject in trait DeadboltHandler of type [A](request: play.api.mvc.Request[A])Option[be.objectify.deadbolt.core.models.Subject]; method getSubject has incompatible type

These are compile time errors and produce on getSubject method, because of its return type. I declare its return type as Future[Option[Subject]] and when i use Option[Subject] as a return type, the errors is removed. When i saw example by steve https://github.com/schaloner/deadbolt-2-scala-examples/blob/master/app/security/MyDeadboltHandler.scala, he used Future[Option[Subject]] and there is no error in code when i import code in eclipse. When i compile the code using activator clean compile command there is no compile time error.

CODE: 

override def getSubject[A](request: Request[A]): Future[Option[Subject]] = {
println("Method Start getSubject");
if(!request.headers.get("userId").isEmpty){
   println("If Method Start getSubject");
  val userId = request.headers.get("userId").get;
  userDao.findById(BSONObjectID.apply(userId));
}else{
  println("Else Method Start getSubject");
  Future(Option.empty);
}}

Update

When i am using deadbolt be.objectify" %% "deadbolt-scala" % "2.3.2 dependency version, i got compile time error in eclipse and build run successfully. But when i use be.objectify" %% "deadbolt-scala" % "2.3.3 dependency version i am getting build error also.

Harmeet Singh Taara
  • 6,483
  • 20
  • 73
  • 126

1 Answers1

1

The signature of getSubject changed in 2.3.3 because the integration with the view layer is flawed. The examples also need updating.

In v2.4 (both Java and Scala versions), all interfaces will return Futures and when blocking calls are needed, e.g. by template restrictions, there will be adapters for the interfaces as required with automatic wrapping.

See the 2.3.3 release notes in the README of https://github.com/schaloner/deadbolt-2-scala - specifically, this bit

DeadboltHandler#getSubject returns an Option[Subject] in place of an Future[Option[Subject]]. Where the subject is needed, the internal code will take care of wrapping the call in a Future.

Sorry for the confusion.

Steve Chaloner
  • 8,162
  • 1
  • 22
  • 38
  • Thanks @Steve for you information, but according to my requirements, i need to return future instead of Option. Please click on this link, which help you to explain my requirements, or i think, this is not only my. https://github.com/harmeetsingh0013/playframework-dynamic-authorization-using-deadbolt2/blob/master/app/handlers/MyDeadboltHandler.scala – Harmeet Singh Taara May 04 '15 at 10:20
  • You can always use v2.3.2 - it has the same feature set, but uses Futures. – Steve Chaloner May 04 '15 at 10:21
  • Ok @Steve i understand, but the fact is that, like my example, if some need to used `reactive-mongo`, then without futures, this cause the problem. Please correct me, if i am wrong? – Harmeet Singh Taara May 04 '15 at 10:23
  • I think I'm maybe not understanding your question. The base difference here is, for all user-implemented interfaces: **2.3.2** uses Futures, e.g. `Future[Option[Subject]]` **2.3.3** does not use Futures, e.g. `Option[Subject]` – Steve Chaloner May 04 '15 at 10:34
  • yes @Steve i understand the main difference. But the question is that, if i want to use `reactive-mongo` and return the user from database,` reactive mongo` return the result in future. As i am using in my example: https://github.com/harmeetsingh0013/playframework-dynamic-authorization-using-deadbolt2/blob/master/app/handlers/MyDeadboltHandler.scala. But how we use, Reactive mongo with **2.3.3** version ? – Harmeet Singh Taara May 04 '15 at 12:14
  • The only way to use 2.3.3 with reactive mongo is to collapse the future down to a result and return that, which removes the benefit of non-blocking DB. I suggest you stick with 2.3.2 for now. – Steve Chaloner May 04 '15 at 12:16
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/76900/discussion-between-harmeet-singh-taara-and-steve-chaloner). – Harmeet Singh Taara May 04 '15 at 14:25
  • Thanks @Steve. But i thought this was not good changes in version 2.3.3, because most of the time, mostly developers need to write non-blocking code. What do you think ? – Harmeet Singh Taara May 04 '15 at 14:28
  • It was a good change because it brought Deadbolt 2.3.3 back in line with the other 2.3.x releases. A redesigned approach to asynchronous activity will appear in 2.4.0, which will remain consistent from the first release. – Steve Chaloner May 05 '15 at 11:06
  • Oh you means, our deabolt **2.3.2** only support `Future` other **2.3.x** not? – Harmeet Singh Taara May 05 '15 at 11:35
  • Yes, it was a blip that shouldn't have happened. – Steve Chaloner May 05 '15 at 11:39
  • Thanks @Steve and your blip really helped us :). – Harmeet Singh Taara May 05 '15 at 12:07