I'm using LIFT to serve a RESTful API, and I want this API to allow requests using CORS (Cross-Origin Resource Sharing) for POST. I do have CORS working with GET requests.
I'm having trouble because cross-origin POSTs first call OPTIONS on the given URL, and I haven't figured out how to accept OPTIONS requests with LIFT.
My question is: What do I need to mixin or write to my serve{} block such that I can allow the HTTP verb OPTIONS for a given path in LIFT?
Right now using curl I get:
curl -X OPTIONS http://localhost:8080/path => [404]
I'm using LIFT 2.4-M5 and Scala 2.9.1
EDIT: Based on pr1001's suggestion, I was trying to extend RestHelper like so:
import net.liftweb.http.provider._
import net.liftweb.http._
trait RestHelper extends net.liftweb.http.rest.RestHelper {
protected object Options {
// Compile error here with options_?
// because net.liftweb.http.Req uses LIFT's RequestType
def unapply(r: Req): Option[(List[String], Req)] =
if (r.requestType.options_?) Some(r.path.partPath -> r) else None
}
}
#serializable
abstract class RequestType extends net.liftweb.http.RequestType {
def options_? : Boolean = false
}
#serializable
case object OptionsRequest extends RequestType {
override def options_? = true
def method = "OPTIONS"
}
object RequestType extends net.liftweb.http.RequestType {
def apply(req: HTTPRequest): net.liftweb.http.RequestType = {
req.method.toUpperCase match {
case "OPTIONS" => UnknownRequest("OPTIONS")
case _ => net.liftweb.http.RequestType.apply(req)
}
}
def method = super.method
}
I feel like this is more work then I should need to do because I don't want to have to extend Req with my own RequestType impl.
I'm definitely on the lower level of skill set when it comes to Scala, so I'm hoping someone can provide a bit simpler solution because I'm sure there's something I'm missing.
Are you using RestHelper? If so you'd specify the type of request you want to respond to and return a LiftResponse. There's no OptionRequest in Lift (yet) to use in the partial function you pass to serve() but you should be able to extend RequestType with your own version. Using UnknownRequest – as in UnknownRequest("OPTION") – might also do the trick.
This might also be worth bringing up on the mailing list, as CORS support would be a useful addition...
Many thanks to pr1001 for his suggestion. I was able to get it working with the following:
import net.liftweb.http._
class RequestTypeImproved(requestType: RequestType) {
def options_? : Boolean = requestType.method == "OPTIONS"
}
trait RestHelper extends net.liftweb.http.rest.RestHelper {
implicit def req2ReqImproved(requestType: RequestType): RequestTypeImproved = {
new RequestTypeImproved(requestType)
}
protected object Options {
def unapply(r: Req): Option[(List[String], Req)] =
if (r.requestType.options_?) Some(r.path.partPath -> r) else None
}
}
Then:
serve {
case req # "path" Options _ => {
LiftResponse(...)
}
}
Related
I am looking to use ScalaJ-Http as a http client. Link: https://github.com/scalaj/scalaj-http
How would I mock Http or HttpRequest in a unit test for a class with a line of code like this val response: HttpResponse[String] = Http("http://foo.com/search").param("q","monkeys").asString?
The class will take the url and params from method call arguments. So I cannot inject HttpRequest.
What I did was create a ScalajHttp wrapper class like so:
import scalaj.http.{Http, HttpRequest}
/**
* This wraps the Scalaj Http object so it can be injected.
*/
class ScalajHttp {
def url(url: String): HttpRequest = Http(url)
}
Then you can easily inject it into another class:
class Foo(http: ScalajHttp) {
def doBar() = {
val response = http.url("http://...").asString
}
}
Then for mocking you can use something like Specs2 and create mock of ScalajHttp.
Curious if you already had a solution for this. I came across your post with the same question.
I finally solved it for now by just creating a 'dummy-service' in the test itself using Scalatra/Jetty and specifying the expected responses in there. So, it's not really mocking, but it'll do for me.
Downside to this approach is that you have to include Scalatra, Jetty-server and Jetty-servlet as extra dependencies (optionally with scope=test).
def mockService: Server = {
class MockedServlet extends ScalatraServlet {
get("/") {
// fill in whatever you expect here
Ok("I'm alive!")
}
}
class ServletMounter extends LifeCycle {
override def init(context: ServletContext): Unit = {
context.mount(new MockedServlet, "/mock")
}
}
new Server(20002) {
val servlet = new ServletContextHandler(ServletContextHandler.NO_SESSIONS) {
addEventListener(new ScalatraListener() {
override def probeForCycleClass(classLoader: ClassLoader): (String, LifeCycle) = {
(classOf[ServletMounter].getSimpleName, new ServletMounter)
}
})
}
setHandler(servlet)
}
}
private val server = mockService
override protected def beforeAll(): Unit = {
super.beforeAll()
server.start()
}
override protected def afterAll(): Unit = {
server.stop()
server.destroy()
super.afterAll()
}
// a simple test
"service up" should "return a 200 when the mocked service is up" in {
val response = Http("http://localhost:20002/mock/").asString
response.code shouldBe 200
response.body shouldBe "I'm alive!"
}
Edit March 2nd, 2017:
After some more consideration I changed my code such that I have the HTTP call via scalaj-http in a 'facade' trait, that I am able to mock in my tests. Now, rather than doing the actual HTTP request, I mock the facade and send back the expected HTTPResponse. In comparison with the solution shown above, this is much cleaner, the dependencies mentioned above aren't necessary anymore and the setup is easier. The facade can be 'injected' into the class that does the HTTP call as either a constructor parameter or as a self-type annotation.
I'm using Play! 2.4 with Deadbolt2 for authorization. However, since I introduced the authorization rules, I'm unable to write successful tests for my controllers. As an example:
class VisitController #Inject() (authorization: DeadboltActions) extends Controller {
def fetchDailyVisits(date: Date) = authorization.Restrict(List(Array(ADMIN_ROLE), Array(MANAGER_ROLE))) {
Action.async {
visitService.findDailyVisits(date).map(result =>
Ok(Json.toJson(result))
)
}
}
}
I'm using specs2 in the tests. My test looks like this atm:
class VisitControllerSpec extends PlaySpecification with Mockito with ScalaFutures {
val deadboltActions = mock[DeadboltActions]
"VisitControllerSpec#fetchDailyVisits" should {
val testDate = Date.from(LocalDate.of(2016, 2, 25)
.atStartOfDay(ZoneId.systemDefault()).toInstant)
"Return Status Ok with returned list" in {
val expected = List(completeVisitWithId, anotherCompleteVisitWithId)
visitService.findDailyVisits(testDate) returns Future { expected }
val request = FakeRequest(GET, "/visits?date=2016-02-25")
val result = new VisitController(deadboltActions)
.fetchDailyVisits(testDate)(request)
result.futureValue.header.status must beEqualTo(OK)
contentAsJson(result) must_== Json.toJson(expected)
}
}
}
How do I mock deadboltActions in a way I can specify the user will be allowed access?
Is there another way? Maybe by providing a different DeadboltHandler? It seems kind of obvious this would be the way to go, I just don't seem to be able to figure it out and there aren't a lot of Deadbolt2 examples out there (at least for scala).
Or, being more extreme, any other authorization framework out there that works well with scala play and allows to handle security as a cross-cutting concern without poluting the controllers? Deadbolt2 is too limited for this reason, but I honestly can't find a better authorization framework (unless I write my own).
There are a number of different ways you can do this.
If your DeadboltHandler has a DAO injected for accessing the subject, you can override the binding of the DAO to provide one containing test subjects.
abstract class AbstractControllerSpec extends PlaySpecification {
sequential
isolated
def testApp: Application = new GuiceApplicationBuilder().in(Mode.Test).bindings(bind[SubjectDao].to[TestSubjectDao]).build()
}
See the test app for an example of using this approach.
Alternatively, you can extend your DeadboltHandler implementation to override getSubject and provide a test subject from here. The binding is handled in the same way as above.
Finally, you can keep all your code as-is and populate the test database with subjects; the requests you send will be shaped by your authentication requirements (headers, something in a cookie, etc).
For unit testing, something similar applies. Given a SubjectDao that has some hard-coded subjects for test purposes, you can use WithApplication and an injector look-up to get what you need.
class TestSubjectDao extends SubjectDao {
val subjects: Map[String, Subject] = Map("greet" -> new SecuritySubject("greet",
List(SecurityRole("foo"),
SecurityRole("bar")),
List(SecurityPermission("killer.undead.zombie"))),
"lotte" -> new SecuritySubject("lotte",
List(SecurityRole("hurdy")),
List(SecurityPermission("killer.undead.vampire"))),
"steve" -> new SecuritySubject("steve",
List(SecurityRole("bar")),
List(SecurityPermission("curator.museum.insects"))),
"mani" -> new SecuritySubject("mani",
List(SecurityRole("bar"),
SecurityRole("hurdy")),
List(SecurityPermission("zombie.movie.enthusiast"))),
"trippel" -> new SecuritySubject("trippel",
List(SecurityRole("foo"),
SecurityRole("hurdy")),
List[SecurityPermission]()))
override def user(userName: String): Option[Subject] = subjects.get(userName)
}
With a controller that looks something like this:
class Subject #Inject()(deadbolt: DeadboltActions) extends Controller {
def subjectMustBePresent = deadbolt.SubjectPresent()() { authRequest =>
Future {
Ok("Content accessible")
}
}
}
We can then unit test it like this:
import be.objectify.deadbolt.scala.DeadboltActions
import be.objectify.deadbolt.scala.test.controllers.composed.Subject
import be.objectify.deadbolt.scala.test.dao.{SubjectDao, TestSubjectDao}
import play.api.Mode
import play.api.inject._
import play.api.inject.guice.GuiceApplicationBuilder
import play.api.mvc.{Result, Results}
import play.api.test.{FakeRequest, PlaySpecification, WithApplication}
import scala.concurrent.Future
object SubjectPresentUnitSpec extends PlaySpecification with Results {
"Subject present " should {
"should result in a 401 when no subject is present" in new WithApplication(new GuiceApplicationBuilder().in(Mode.Test).bindings(bind[SubjectDao].to[TestSubjectDao]).build()) {
val deadbolt: DeadboltActions = implicitApp.injector.instanceOf[DeadboltActions]
val controller = new Subject(deadbolt)
val result: Future[Result] = call(controller.subjectMustBePresent(), FakeRequest())
val statusCode: Int = status(result)
statusCode must be equalTo 401
}
"should result in a 200 when a subject is present" in new WithApplication(new GuiceApplicationBuilder().in(Mode.Test).bindings(bind[SubjectDao].to[TestSubjectDao]).build()) {
val deadbolt: DeadboltActions = implicitApp.injector.instanceOf[DeadboltActions]
val controller = new Subject(deadbolt)
val result: Future[Result] = call(controller.subjectMustBePresent(), FakeRequest().withHeaders(("x-deadbolt-test-user", "greet")))
val statusCode: Int = status(result)
statusCode must be equalTo 200
}
}
}
It doesn't answer exactly to my original question, which was mostly related with Deadbolt2, but I kept getting frustrated with the fact I had to specify my authorization rules in my controllers, which is not truly cross cutting.
The answer provided by Steve Chaloner helps, but still forced me to go through a few hoops.
Enter Panoptes. This authorization framework is based on Filters instead of Action chaining, so it allows to easily specify authorization rules in a central location and outside of the controllers.
Setting your security rules in Panoptes is somewhat similar to Spring Security and it looks like this:
class BasicAuthHandler extends AuthorizationHandler {
override def config: Set[(Pattern, _ <: AuthorizationRule)] = {
Set(
Pattern(Some(POST), "/products") -> atLeastOne(withRole("Admin"), withRole("Manager"))
Pattern(Some(GET), "/cart[/A-Za-z0-9]*") -> withRole("Admin"),
Pattern(None, "/orders[/A-Za-z0-9]*") -> withRole("Admin")
)
}
}
Other than that, you need a couple of lines to declare the filter and plug in your AuthorizationHandler.
class Filters #Inject()(securityFilter: SecurityFilter) extends HttpFilters {
override def filters = Seq(securityFilter)
}
class ControllerProviderModule extends AbstractModule {
override def configure(): Unit = { bind(classOf[AuthorizationHandler]).to(classOf[MyAuthorizationHandler])
}
}
The README file in the git repository has more details and code samples.
It's also customizable to the point it allows to create your own AuthorizationRules. In my project I have a requirement where I need to check the mobile device that makes the call is registered in the system. I can write an AuthorizationRule to handle this for me for every request whose path matches my pattern.
Unit testing controllers is extra simple, because any mocking of the security layer can be ommited. They can be tested like any other class.
If you're having similar issues or also believe authorization rules don't belong in the controllers, have a go at Panoptes, it might suit your needs. Hope this helps someone else.
Combining an ActionBuilder that transforms a request into a custom WrappedRequest with an additional type parameter, and then combining that with an ActionFilter causes the type of the custom WrappedRequest to be dropped.
Why is this and is there a fix?
For example, lets say I need to an authentication ActionBuilder and an optional, authorisation ActionFilter where the user type we need can vary depending on use.
See this contrived code:
case class AuthRequest[A, U](val request: Request[A], val user: U) extends WrappedRequest[A](request)
case class TestUser(id: String)
case class AuthenticationAction[A]() extends ActionBuilder[({type λ[B] = AuthRequest[B, TestUser]})#λ] {
override def invokeBlock[A](request: Request[A], block: (AuthRequest[A, TestUser]) => Future[Result]): Future[Result] =
block(AuthRequest(request, TestUser("test-id")))
}
case class AuthorisedAction[A]() extends ActionFilter[({type λ[B] = AuthRequest[B, TestUser]})#λ] {
// does some additional authorisation checks for added security
def authorised(user: TestUser) = true
override def filter[A](request: AuthRequest[A, TestUser]) = Future.successful {
if( authorised(request.user) ) None
else Some(Unauthorized)
}
}
Please note: The type function in the above is required as per this answer because of the additional type parameter on the AuthRequest. Again this is required because this API will be used with more than one type of user.
If I then implement a controller that uses the above:
class ExampleController extends Controller {
def secured = (AuthenticationAction() andThen AuthorisedAction()) { request =>
Ok(request.user.id)
}
}
I get a compiler error (value user is not a member of play.api.mvc.WrappedRequest[play.api.mvc.AnyContent]). In other words, the type of the variable request above is WrappedRequest instead of the expected type of AuthRequest[play.api.mvc.AnyContent, TestUser]!
I understand that most use cases the AuthenticationAction and AuthorisedAction would be combined into a single action but, because authorisation is optional, I would like to keep these as separate concerns.
Is this possible? Is this a bug in the Play Framework API? Or a Scala bug? Or human error?
Using your example I was able to compose the actions like this:
class ExampleController extends Controller {
def secured = AuthorisedAction().compose(AuthenticationAction()) { request =>
Ok(request.user.id)
}
}
It's interesting to note that in both cases IntelliJ's type inspection sees request as being of type AuthRequest[AnyContent, TestUser] -- it's only scalac that sees it as a WrappedRequest.
Here's an authorisation example from Play Documentation (version 2.0.4; I tried to find a newer version of this document but couldn't):
trait Secured {
def username(request: RequestHeader) = request.session.get(Security.username)
def onUnauthorized(request: RequestHeader) = Results.Redirect(routes.Auth.login)
def withAuth(f: => String => Request[AnyContent] => Result) = {
Security.Authenticated(username, onUnauthorized) { user =>
Action(request => f(user)(request))
}
}
def withUser(f: User => Request[AnyContent] => Result) = withAuth { username => implicit request =>
UserDAO.findOneByUsername(username).map { user =>
f(user)(request)
}.getOrElse(onUnauthorized(request))
}
}
Overall this is pretty straightforward, and I'd like to go with something like this.
Now, in Play 2.4 the recommended way is not to use singletons anymore (like UserDAO above), but classes and runtime DI instead (see migration guide, or DI docs).
For example, my service and repository classes are defined like this:
class AuthService #Inject()(accountRepo: AccountRepository) { }
class AccountRepository { }
With Play 2.4 and DI in use, what is the recommended / "correct" / simplest way to get hold of a service or DAO (like AuthService in my case, or UserDAO in the doc example) in a trait like Secured?
Or are you nowadays supposed to implement authorisation for controllers in a whole another way than using such trait?
I can make it work along these lines:
trait Secured {
val authService = GuiceUtils.inject[AuthService]
// ...
}
Using a helper like this:
object GuiceUtils {
lazy val injector = new GuiceApplicationBuilder().injector()
def inject[T: ClassTag]: T = injector.instanceOf[T]
}
But according to an answer in a related question:
In Play you could use the injector directly as long as the Application
trait is in scope. But this isn't considered good practice in
production code.
If that is true, what is considered good practice in this use case?
I think the simplest approach would be to declare the authService in your trait but keep it abstract, then have the controller which extends it handle the injection (I believe this is how MessagesApi/I18nSupport injection works). So you could do:
trait Secured {
val authService: AuthService
...
}
controller Application #Inject()(override val authService: AuthService) extends Controller with Secured {
...
}
Background
I am trying to understand best practices for bringing implicit objects into scope within a Scala application.
I have a Playframework 2.2.0 (Scala 2.10) web app that mixes in a trait for Authorization. It checks. The Authenticated object checks that there is a user_id in scope, attempts to retrieve the user info, access token, and a data package object called a MagicNotebook from cache, database, and web service call. If the request is valid, then various objects are added to the wrapped request.
object Authenticated extends ActionBuilder[AuthenticatedRequest] {
def invokeBlock[A](request: Request[A],
block: (AuthenticatedRequest[A] => Future[SimpleResult])) = {
request.session.get(userName).map { implicit userId =>
Cache.getAs[DbUser](userKey).map { user =>
Cache.getAs[String](accessTokenKey).map { accessToken =>
Cache.getAs[MagicNotebook](magicNotebookKey(userId)).map { notebook =>
block(AuthenticatedRequest(user, accessToken, notebook, request) )
}.getOrElse(startOver)
}.getOrElse {
requestNewAccessToken(user.token).flatMap { response =>
persistAccessToken(response).map { accessToken =>
Cache.getAs[MagicNotebook](magicNotebookKey(userId)).map { notebook =>
block(AuthenticatedRequest(user, accessToken, notebook, request))
}.getOrElse(startOver)
}.getOrElse(startOver)
}
}
}.getOrElse(startOver) // user not found in Cache
}.getOrElse(startOver) // userName not found in session
}
}
}
case class AuthenticatedRequest[A](user: DbUser,
accessToken: String,
magic: MagicNotebook,
request: Request[A])
extends WrappedRequest[A](request)
Question
What is the best way to bring these implicit variables into scope?
Through an implicit class?
I tried to use an implicit companion class, with the following code:
object Helper {
implicit class Magical(request: AuthenticatedRequest[AnyContent]) {
def folderMap = request.magic.fMap
def documentMap = request.magic.dMap
}
}
However, I don't really get the benefit of an implicit this way:
def testing = Authenticated { implicit request =>
import services.Helper._
request.magic.home.folders // doesn't compile
request.magic.home.folders(Magical(request).ffMap) // compiles, but not implicitly
Ok("testing 123")
}
Through an import statement?
One possibility I considered was through an import statement within the controller. Here, the request has a MagicNotebook object in scope that I would like to use as an implicit variable.
def testing = Authenticated { implicit request =>
import request.magic._
request.magic.home.folders // implicit map is a parameter to the `folder` method
Ok("testing 123")
}
Through a companion trait?
Here, I create a companion trait that is mixed into the Authenticate trait that includes the two maps of the MagicNotebook object into scope of the controller.
trait Magic {
implicit def folderMap[A](implicit request: AuthenticatedRequest[A]) =
request.magic.fMap
implicit def docMap[A](implicit request: AuthenticatedRequest[A]) =
request.magic.dMap
}
My preference is the companion trait solution, but I was wondering if there might be a better way that I overlooked. I ended up re-writing methods that use the implicit variable, to use the MagicNotebook's two maps instead of whole object as implicit parameters.
But again, I was wondering if there might be a better way.
I am quite partial to package objects for this sort of thing. See What's New in Scala 2.8: Package Objects for a description. Package objects effectively allow you to put implicit classes into a package, which you can't otherwise do.
However, the main snag with this approach is that you can't split the definition of an object across multiple source files, so because the implicit classes need to be defined within the package object, they also need to be all in the same source file. If you have many implicit classes you wish to have imported, this can result in a large and unwieldy source file. However, that in itself is a sign that you have a “package god object” which should be split.
One of the ways I know of defining implicits is by using Package Objects.
package implicitIdiomatic {
implicit def nullableLongToOption(l:java.lang.Long) = Option(l)
}
}
package implicitIdiomatic
class ImplicitIdiomaticTest{
val l:Long = 1
longOpt(l)
def longOpt(l:Option[Long]) = l match {case Some(l1) => println(l1); case None => println("No long")}
}
Kind of useless example but hope you get the idea. Now when longOpt gets l, it is converted to Option[Long] using the implicit.
As long as you are working in the same package as defined by the package object you don't need the import statement.