Make SecuredRequest and UserAwareRequest traits

[wsargent]

Purpose

This PR changes SecuredRequest from a case class to a trait, and adds a SecuredRequestHeader trait as well.

This makes it easier to change the implementation of a secured request because a wrapped request may want to implement secured request behavior, i.e. the identity and authenticator, but cannot because there is not a trait for it.

Because there is a factory method which uses the default impl behind the scenes, this should have no impact on user facing code (although I have not tried binary compatibility, etc.)

Background Context

This is the approach used for extending Play requests internally, i.e. in https://github.com/playframework/playframework/blob/2.6.x/core/play/src/main/scala/play/api/mvc/MessagesRequest.scala

Note that the request body should be covariant per playframework/playframework#8240

[coveralls]

Coverage decreased (-0.07%) to 95.83% when pulling a00e861 on wsargent:make-secured-request-trait into 12976ca on mohiva:master.

[coveralls]

Coverage decreased (-0.06%) to 95.833% when pulling 37f60dd on wsargent:make-secured-request-trait into 12976ca on mohiva:master.

[akkie]

This makes it easier to change the implementation of a secured request because a wrapped request may want to implement secured request behavior, i.e. the identity and authenticator, but cannot because there is not a trait for it.

Do you have a concrete example for this? The SecuredRequest itself cannot be changed by the user, because it will only be instantiated in Silhouette. So I currently see no reason to make this a trait. Maybe I miss something!?

[wsargent]

@akkie created mohiva/play-silhouette-seed#118 as a concrete example

[wsargent]

So the issue is more about being able to expose SecuredRequest as a behavior, so that MyRequestHeader can extend both MessagesRequestHeader and SecuredRequestHeader and have Twirl fragments be able to pass in the specific behavior needed:

@()(implicit provider: MessagesProvider) 
@* MessagesRequestHeader is a MessagesProvider 
from https://www.playframework.com/documentation/2.7.x/ScalaForms#Option-Two:-Use-MessagesRequest 
*@

or for a username fragment (for example in the navbar):

@()(implicit request: SecuredRequestHeader) @* render the identity etc *@

Thinking about it a bit more, this could be broken down more into IdentityProvider and AuthenticatorProvider:

trait SecuredMessagesHeader extends IdentityProvider with AuthenticatorProvider

And then the twirl code wouldn't have to be tied directly to the request:

@()(implicit identityProvider: IdentityProvider) @* render the identity etc *@

[akkie]

I think the only thing that could probably break current code is the ability to pattern match against the current implementation. So I think this pull request needs an unapply method too in the companion object.

[wsargent]

So I think this pull request needs an unapply method too in the companion object.

Sorry, I'm lost. What companion object are we talking about? Both SecuredRequest and UserAwareRequest?

[akkie]

Yes, I meant both companion objects. In the old implementation both request types were case classes, which a user could pattern match on. Currently this isn't possible. I'm not sure it's really a use case to pattern match on the request types. What do you think?

[wsargent]

Can't hurt, I'll add it.

[wsargent]

Done. I see a failure on higher kinded types, not sure about touching the CI build system though.

[akkie]

Thanks Will 👍