Custom views in SecureSocial in Java

Question

I saw a few questions about this topic, but none answer the part I am stuck on. By the way, based on the issues people are running into, I might suggest giving a default java implementation of the TemplatesPlugin after all.

The problem I have, is that I copied the two needed views from SecureSocial to my views folder, and changed the RequestHeader as others have noted to: play.api.mvc.RequestHeader and now I am getting:

ambiguous implicit values: both method requestHeader in object PlayMagicForJava of type => play.api.mvc.RequestHeader and value request of type play.api.mvc.RequestHeader match expected type play.api.mvc.RequestHeader

Version: Play-2.1.1, Java 7, SecureSocial from Master.

EDIT:

Play Compile:

[error] C:\Java\AwsConsole\app\views\secure\login.scala.html:41: ambiguous impli
cit values:
[error]  both method requestHeader in object PlayMagicForJava of type => play.ap
i.mvc.RequestHeader
[error]  and value request of type play.api.mvc.RequestHeader
[error]  match expected type play.api.mvc.RequestHeader
[error]                         @provider(p.id)
[error]                                  ^
[error] C:\Java\AwsConsole\app\views\secure\provider.scala.html:20: ambiguous im
plicit values:
[error]  both method requestHeader in object PlayMagicForJava of type => play.ap
i.mvc.RequestHeader
[error]  and value request of type play.api.mvc.RequestHeader
[error]  match expected type play.api.mvc.RequestHeader
[error]                 <form action = "@securesocial.core.providers.utils.Route
sHelper.authenticateByPost("userpass").absoluteURL(IdentityProvider.sslEnabled)"

[error]
                                                  ^
[error] two errors found
[error] (compile:compile) Compilation failed

Browsing after Play Run instead:

Internal server error, for (GET) [/] ->

sbt.PlayExceptions$CompilationException: Compilation error[ambiguous implicit va
lues:
 both method requestHeader in object PlayMagicForJava of type => play.api.mvc.Re
questHeader
 and value request of type play.api.mvc.RequestHeader
 match expected type play.api.mvc.RequestHeader]
        at sbt.PlayReloader$$anon$2$$anonfun$reload$2$$anonfun$apply$15$$anonfun
$apply$16.apply(PlayReloader.scala:349) ~[na:na]
        at sbt.PlayReloader$$anon$2$$anonfun$reload$2$$anonfun$apply$15$$anonfun
$apply$16.apply(PlayReloader.scala:349) ~[na:na]
        at scala.Option.map(Option.scala:133) ~[scala-library.jar:na]
        at sbt.PlayReloader$$anon$2$$anonfun$reload$2$$anonfun$apply$15.apply(Pl
ayReloader.scala:349) ~[na:na]
        at sbt.PlayReloader$$anon$2$$anonfun$reload$2$$anonfun$apply$15.apply(Pl
ayReloader.scala:346) ~[na:na]
        at scala.Option.map(Option.scala:133) ~[scala-library.jar:na]

I have this problem as well in the 2.1.1 version.. no solution yet — adis, Apr 30 '13 at 17:34
Can you please post the full error message so that it becomes clear in which line of which template the error occurs. — MartinGrotzke, May 01 '13 at 07:56
@MartinGrotzke Updated the question with the stack traces from compile and from run — Chanan Braunstein, May 01 '13 at 13:19
For those interested in custom securesocial templates with play java, this is also discussed here (how to access the flash scope from main template used also by login template): https://github.com/jaliss/securesocial/issues/253 — MartinGrotzke, Jul 28 '13 at 21:13

MartinGrotzke · Accepted Answer · 2013-05-02T07:47:43.887

The request must be passed explicitely to the login template, the login template must pass the request explicitely to the provider template and the provider template must specify the request when invoking RoutesHelper.authenticateByPost("userpass").absoluteURL. More detailed:

The java TemplatesPlugin should have this getLoginPage implementation:

@Override
public <A> Html getLoginPage(final play.api.mvc.Request<A> request, final Form<Tuple2<String, String>> form,
        final Option<String> msg) {
    return views.html.login.render(request, form, msg);
}

The parameters (first line) of login.scala.html should look like this:

@(request: play.api.mvc.RequestHeader, loginForm: play.api.data.Form[(String,String)], errorMsg: Option[String] = None)

Change calls from login.scala.html to the provider template to pass the request explicitely (we'll adjust its parameters in the next step).
1. login.scala.html line 41, change
```
@provider(p.id)
```
  to
```
@provider(request, p.id)
```
2. login.scala.html line 55, change
```
@provider("userpass", Some(loginForm))
```
  to
```
@provider(request, "userpass", Some(loginForm))
```

The parameters (first line) of provider.scala.html should take the request as first, explicit parameter:

@(request: play.api.mvc.RequestHeader, providerId: String, loginForm: Option[play.api.data.Form[(String, String)]] = None)

Line 20 of the provider template needs to pass the request (so that the correct method is invoked, otherwise you'll get a RuntimeException: There is no HTTP Context available from here):
```
<form action = "@securesocial.core.providers.utils.RoutesHelper.authenticateByPost("userpass").absoluteURL(IdentityProvider.sslEnabled)(request)"
```

This should be all needed changes, if you're using other templates they would have to be adjusted accordingly.

Just to mentiond it: I had changed our java TemplatesPlugin to a scala version (to have it more straight forward).

That almost worked. Well, it works for me, since I am only using userpass. The error I got was on the @provider(p.id). I just removed that and placed the contents of provider.scala.html into login.scala.html. Others will have a problem though. — Chanan Braunstein, May 02 '13 at 02:02
@ChananBraunstein I already wrote this: "(the calls from login template needs to be adjusted accordingly - pass the request as first argument)" - even with this it didn't work? I'll pull this into a separate bullet point so that it's more visible. — MartinGrotzke, May 02 '13 at 07:40
@ChananBraunstein If you use provider.scala.html again, does it work for you with adjusted calls to the provider template (new item 3.)? — MartinGrotzke, May 02 '13 at 07:49
Yes, you are right on both counts, I did miss that part of your answer, and yes it does work. Thanks for your help! — Chanan Braunstein, May 02 '13 at 13:45

Custom views in SecureSocial in Java

1 Answers1