Migrate to play 2.6

[KadekM]

For #343

https://github.com/joscha/play-easymail/issues/53 is required, so this builds:

"com.feth" %% "play-easymail" % "0.9.3"

[joscha]

guys, please stay civil. I appreciate all your contributions but personal attacks can not be tolerated.

FWIW I am not sold 100% on Ebean, I have heard good things about jooq, but not a lot of experience with it, same with a few others. Backwards compatibility and also some amount of the standard way of doing persistence with Play is important though, so I am a bit wary of throwing Ebean out and replacing it with something as unknown as perfectjpattern - the software might be great, I wouldn't know, I've never used it, but it would certainly be quite hard for anyone to use it unless we assumed they would adopt a new (quite unknown and seemingly not very widespread used ORM) together with an authentication library. I don't think that is a sellable package?

[schaloner]

jOOQ is very good, but be aware of the licensing restrictions for commercial databases. If the target database isn't open source, you are required to pay for a license.

See https://www.jooq.org/download/ for details.

[GBeushausen]

@bravegag: I didn't want to sound rude, neither did i wanted to boast with my income, i just wanted to express the view of commercial software developers. So please don't take it personal.

I already offered to contribute financially to find a solution for this problem. Maybe someone can set up a crowd funding page or something.

@schaloner: Thanks for this information. This would be a heavy burden for this project, if commercial developers have to pay License fees for software they didn't even want to use. I think if this project really wanted to move away from Ebean, it should be either JPA or Spring data. If at all. Ebean is so common in the Play community.

[joscha]

I just fired up https://github.com/joscha/play-authenticate/tree/play2.6-migration again to give EBean another spin - I am not even sure where it fails - tbh I am not even sure if it is EBean - the only thing I can say for certain is, that there is something wrong which makes deadbolt think a user is not authenticated. Please use the referenced branch if you want to help, any hints are appreciated!

[joscha]

as a matter of fact with a tweaked logback I can now see a:

[warn] p.filters.CSRF - [CSRF] Check failed because no or invalid token found in body for /signup
[warn] p.filters.CSRF - [CSRF] Check failed with NoTokenInBody for /signup

best clue so far, will push my current state of the branch

[GBeushausen]

@joscha: Great, i'll give it a try, though i don't have much time. Btw, what happens if you disable security filters?

[joscha]

I think I have it working via @helper.CSRF.formField - will push the changes, but it will need some cleanup I think.

[joscha]

I think #364 is working with 2.6 - will wait for CI - an awful lot of deprecation warnings though, mainly around the form helpers. Probably time to get rid of them soon. Would be good if someone else could give what is in #364 a spin and read over the changes.

[joscha]

okay, https://github.com/joscha/play-authenticate/pull/364 is almost ready to be merged - I can't get the Selenium tests to pass right now and they won't start locally for me for some reason (gecko driver?). Can anyone else give them a try? You should be able to start and pass them via:

export GOOGLE_USER_PASSWORD="..." \
       GOOGLE_CLIENT_ID="..." \
       GOOGLE_CLIENT_SECRET="..." \
       EVENTBRITE_CLIENT_ID="..." \
       EVENTBRITE_CLIENT_SECRET="..." \
       EVENTBRITE_USER_PASSWORD="..." \
       FACEBOOK_USER_PASSWORD="..." \
       FACEBOOK_CLIENT_ID="..." \
       FACEBOOK_CLIENT_SECRET="..."
sbt --info test

[joscha]

Version 0.9.0 for Play 2.6 should show up here soon: https://mvnrepository.com/artifact/com.feth/play-authenticate

I had to disable integration tests due to browser issues to get the release done. Let me know how you fare. Sorry it took so long, anyone reading here should probably put their hand up for becoming a maintainer, so we can avoid these delays in the future.