[warn] /Users/plamb/Documents/Personal/Coding/portlandpaella/app/controllers/auth/AuthConfigImpl.scala:32: method maybeApplication in object Play is deprecated: This is a static reference to application, use DI instead
[warn] cookieSecureOption = play.api.Play.maybeApplication.exists(app => play.api.Play.isProd(app)),
[warn] ^
[warn] /Users/plamb/Documents/Personal/Coding/portlandpaella/app/controllers/auth/AuthConfigImpl.scala:32: method isProd in object Play is deprecated: inject the play.api.Environment instead
[warn] cookieSecureOption = play.api.Play.maybeApplication.exists(app => play.api.Play.isProd(app)),
@gakuzzzz so i need SSL enabled on my site?
is it possible to NOT use SSL in prod? or is that really bad?
i’d like to just test that SSL enabling is exactly the problem
@gakuzzzz just to be clear, by that you mean https right
was able to login fine
1) I noticed its been a while since there's been any updates to the code. Is active development suspended at this time?
2) from what I understand, authenticated tokens are cached server side. Is there risk of these tokens aging out of the cache?
Is there any way to send the
user information in the loginSucceeded method?
For instance, send the Full name
Hi!
I'm trying to use play2-auth also for my websocket controller but I don't see a way to conveniently get the session ID for a logged in user. I am now overwriting a lot of methods / writing my own classes already. Is there a built-in support or a different module that handles this in a good way? I need the session ID because I need to cut the websocket connection on logout.
Thanks!
Controller with AsyncAuth {
def socket: WebSocket = WebSocket.acceptOrResult[String, String] { implicit request =>
authorized(isLoggedIn).map {
case Left(_) => Left(Forbidden)
case Right((user, _)) =>
Right {
ActorFlow.actorRef(out => {
actorManager.agentWebsocketServer ! (out, user.id.get)
AgentClientActor.props(out, actorManager, user)
})
}
}
}
}
quickly copied out of my code
AsyncAuth is the trick
@ChickenSniper Kind of. We rely heavily on play2-auth, so we've been working on a fork that allows it to with runtime DI in Play 2.5.x and on. The basic functionality is the same, but now all components are runtime injectable and all weird globals have been stomped out. https://github.com/jaroop/play-sentry
Still putting the finishing touches on it, but 1.0.0-SNAPSHOT is published to sonatype for any one that's interested. I expect to finalize it within a week or two.
Unless some brave soul can find another way to make it work.
I don't know if it's theoretically possible with runtime DI. The main roadblock that I ran into is that
AuthConfig contains three type aliases, which made it difficult to make that component (and basically all others) difficult to inject and runtime and also know about the correct types at compile time. Using a type parameter (same trick that play-silhouette uses) cut down on the required boilerplate, but I couldn't find a way to make it work without guice.
As I needed
TypeLiteral bindings in the module.
It looks like play-silhouette only works with guice right now, too.
We opted not to use silhouette because it is massive and would require a decent amount of rework in our applications with the risk of it also becoming abandonware down the road. Porting play2-auth to work with guice was straightforward enough, but with some limitations to keep a similar API.
Confining ourselves to guice was a small sacrifice since Play seems to provide the most out-of-the-box support for it.
Yes, most examples for it and play use guice
I think play is moving away from that though
It's very unidiomatic Scala, and really unnecessary
Play attempts to provide an API that is DI framework agnostic, but I don't think they're "moving away from that". That was kind of the entire reason this library ceases to work in Play 2.6. To say a DI framework is unnecessary (if that's what you meant to say) though is very dismissive. I was resistant at first, but it has taken away many headaches from building and testing applications. .. but that's neither here nor there.