"Remember Me" functionality?

[bravegag]

Hi, is the "Remember Me" functionality implemented somewhere? maybe an open PR? I'd like to have that. I'm soon implementing a new application and need this plus other stuff. Also, is there anyone who knows Scala well and can help me with this "Remember Me" functionality?

I'd like to have the improvements done in this fork:
https://github.com/bravegag/play-authenticate-usage-scala

and I'm also happy to get them in the PA repo.

[bravegag]

We are now two developers trying to implement a reusable "Remember Me" functionality. I did a fresh fork of PA under https://github.com/bravegag/play-authenticate in order to add this, expect a PR soon. I have also brought back an old attempt to introduce a reusable "Remember Me" functionality from here:
smola@da6a38b. Any help with this will be most welcome and I will be happy to add anyone to help with this PR in my fork.

After reviewing all comments e.g. #38, code etc it seems to me that the attempt from user @smola didn’t make it to PA master due to:

I have this approach integrated in my app and seems to be working. But it's still not clear to me where should remember me be hooked for proper integration with play-authenticate.

I have a solution in mind, but need to think over the details and prepare a PoC. My approach for a clean "Remember Me" would be to (also inspired in the article: http://jaspan.com/improved_persistent_login_cookie_best_practice):

1. Create an ActionCreator or Filter that will intercept HTTP requests and check whether a "Remember Me" cookie is set. This class component will get injected the concrete implementation of CookieAuthProvider and other bits from PA needed to accomplish the "Remember Me". I think this approach should work cleanly because "Remember Me" is a cross cutting concern and doesn't make sense to copy-paste it in each AuthProvider implementation.
2. Check for possible cookie theft and if so then clears the token history for this user, requests a re-login and shows a message like "We have verified a suspicious activity in your login history and require you to re-authenticate i.e. your authentication cookie may have been stolen". This case corresponds to a matching series but wrong token (possibly because a thief logged in in-between). In the article this is described:

If the username and series are present but the token does not match, a theft is assumed. The user receives a strongly worded warning and all of the user's remembered sessions are deleted.

3. Add sudo level re-login. Whenever the user logs in via a "Remember Me" cookie and attempts to access sensitive information e.g. payments, credit card updates etc, the "Remember Me" is invalidated and a re-login re-authenticate request is shown (for example, Github does that and many other web sites). I believe we'd need to use Deadbolt2 to add this sensitiveness or sudo category to certain Actions.

[joscha]

I believe we'd need to use Deadbolt2 to add this sensitiveness or sudo category to certain Actions.

You might want to look at #345 first, to update to latest Play 2.6 before adding a bigger feature on top.

[bravegag]

Hi @joscha! thank you for referring me to #345 it really makes sense indeed to do the migration to Playframework 2.6.x first. I know JPA well and can help switch to that I just don’t have a lot of time but could supervise it if needed. However, AFAIK in PA the EBean bit is only used for the usage samples or? Another possibility is to split PA core from the usage samples that use EBean, and just migrate the core PA to 2.6 temporarily leaving out the samples. For example, in my tested Scala usage sample https://github.com/bravegag/play-authenticate-usage-scala I use Slick that is modern, faster and more productive than the alternatives (though there no Slick for Java AFAIK) furthermore, there I use a clean DAO pattern on top. You could temporarily discontinue the Java usage sample until further notice and introduce the Scala one I have with Slick. Like this we'd have a complete PA mixed Java/Scala project that can be easily migrated to Play 2.6.

I also have an OS project http://perfectjpattern.sourceforge.net/ that could be reused to replace EBean. The unreleased version I have in trunk has throughout JPA support, samples and for multiple JPA providers e.g. Hibernate, OpenJPA, ElipseLink, etc and don't worry the current version is GNU GPL but the unreleased version in trunk is Apache licensed :)

One question, would anyone be willing to make a money pool to sponsor this "Migration 2.6/EBean->JPA" work? I can put down $100 to get it done via Upwork. I really need time to market. I don't know but for me it is critical to have this working ... and if a few guys contribute $100 or less we could sponsor someone migrating this in parallel ..

[leccyril]

If we want to keep ebean how we do ? what is best in JPA/hibernate than ebean ? it means modify all application migration i think it is very heavy and more for those who are using JAVA/ebean ...

[bravegag]

Hi @leccyril, I understand your point and your concerns, if I had my applications written with EBean I would feel the same. I have never used EBean in my projects and I was just giving alternatives to move PA forward. There are many JPA vendor alternatives to EBean. I will now put my perfectjpattern project trunk in Github there I have many examples for multiple vendors, it could be reused or you could simply migrate to pure JPA that, while more verbose, it will be a good long term investment technology-wise for your project in any case.

EBean is not part of the PA core which is what most people actually depend on. EBean is simply a technology choice for the samples. This means people who chose EBean should find the way to migrate their own applications ... but this is my 5c to the problem. I know it is not easy,

[bravegag]

I have moved my http://perfectjpattern.sourceforge.net/ project to Github and now with Apache license.
https://github.com/bravegag/perfectjpattern check out under jee DAO and JPA for the examples on different vendors.

JPA Examples are here:

Using Hibernate: https://github.com/bravegag/perfectjpattern/blob/master/perfectjpattern-examples/src/main/java/org/perfectjpattern/jee/integration/dao/hibernate/Example.java

Using OpenEJB and OpenJPA: https://github.com/bravegag/perfectjpattern/blob/master/perfectjpattern-examples/src/main/java/org/perfectjpattern/jee/integration/dao/jpa/Example.java

Using Hibernate and Spring: https://github.com/bravegag/perfectjpattern/blob/master/perfectjpattern-examples/src/main/java/org/perfectjpattern/jee/integration/dao/spring/Example.java

[bravegag]

We are going to have a "Remember Me" PR soon so better to merge that first, it doesn't look complex to merge.

I propose to later create a separate PR to migrate EBean -> JPA via perfectjpattern it's very easy using the DAO interface ... @joscha you ok with this? We can choose any provider: OpenJPA, Hibernate, ElicpseLink .. which one?

[bravegag]

We have done some progress and here is a merge preview that includes the "Remember Me" functionality described before. The points 1) 2) 3) described above.

master...bravegag:master

We are still code-reviewing and testing it.

[joscha]

Just had a short skim - gist is looking good. Let me know when it is ready.

[bravegag]

Hi @joscha! Could you please take a look at this and help with the momentum we currently have :) as soon as this is done and goes through I will look into the JPA bit to help PA move on to Play 2.6. I need this one to go through first. I think the only error we have is the CI looking and picking a different PA artifact. Locally all compiles and works perfectly.

[joscha]

Hi @bravegag - will have a look on Sunday night, sorry completely booked before. Keep the momentum, it is great!

[bravegag]

@joscha Any progress on this?

[joscha]

sorry, I think I had a look before the 2.6 upgrade - is it rebased against that? Also: can we decouple "remember me" from any change in the persistence layer?