Lexikjwtauthenticationbundle: Version 2.0 - Symfony 2.8 and Symfony 3.0+ compatible only

[slashfan]

Hi,

With Symfony 2.3 support coming to an end in May and Symfony 2.8 introducing great new components such as Guard, it would be interesting to create a new major version and drop support for Symfony 2.7 and below.

That way we could remove all the hack code that tried to maintain compatibility with old Symfony versions, and using using Guard authenticators we could simplify the security layer and provide an out of the box stateless replacement for the form_login.

Any thoughts on this ? It would be great to have your opinion.

Thanks !

---

Currently we have those tasks :

• [x] Remove deprecated calls and hacks which maintained compatibility with old symfony versions (#173)
• [x] Remove class parameters from Resource/config/services.xml (#178)
• [x] Provide a more flexible default encoder through supporting SecLib in addition of OpenSSL (#162)
• [x] Avoid injecting Request objects (#200, #201)
• [x] Add functional tests to test the different workflows : anonymous requests, events dispatched, response codes... (#184)
• [x] Use AppBundle as namespace for code examples in documentation (#243)
• [ ] Replace legacy security system by Guard Authenticators:
  
  
  
  • [x] JWT token authenticator (#184)
  
  
  • [ ] form-login authenticator (#237, closed for now)
  
  

Any idea is welcome.

[lucascherifi]

:+1:

[weaverryan]

:+1: @slashfan I'd like to help with the goals of the next release, if you'll have me :). I agree completely with what your initial ideas. What's the next step?

[slashfan]

Hi @weaverryan it would be great to have your help ! I think the bundle should provide two main authenticators :

• a stateless form login (for the first phase authentication by username and password)
• a jwt authenticator (for the token based authentication).

Fortunately, you have already done most of the job in the symfony con presentation you did in december :)

The idea for the form login authenticator is to provide an alternative to the standard symfony form login. It should be stateless and provide out of the box the logic currently provided by the authentication success and failure handlers. The encoder service and the token TTL should be configurable.

The most important is the jwt authenticator. The decoder service and request token extractors services should be configurable.

Both authenticator should dispatch the current events and provide sensible default configuration.

What's your opinion ? Would you like to work on them ?

[weaverryan]

Hi @slashfan!

Yes, this makes sense: there are two steps (getting the token and then using the token), so it's a good plan :).

Would the stateless form login authenticator set the token on a cookie? Or would this be really more of just an "endpoint" that you could hit to return the token as JSON?

If we're providing "Guard authenticator" classes people can use, then naturally, people will have a lot of flexibility.

Unfortunately, I will not have time to personally work on this. I would to help comment and review - but I need someone else in the community to take the reigns! This is an important bundle for Symfony (in fact, it's in a new version of that Guard prez that I'm giving tomorrow).

Thanks!

[slashfan]

The stateless form login authenticator is indeed more of an endpoint : if the credentials are good, a json response containing the token is returned; otherwise a a 401 response is returned.

Great, I hope the slides will be available :)

[weaverryan]

They are now :) http://www.slideshare.net/weaverryan/symfony-guard-authentication-fun-with-api-token-social-login-jwt-and-more

Cheers!

[chalasr]

@weaverryan Thanks for these great slides that give a lots of ideas.

@slashfan I would be glad to help on this way.
Maybe I can begin to work on the form login authenticator ?

Let me know of where we should start and how you are thinking it, this major release is a really important step.

[slashfan]

@chalasr I already have a wip local branch, I'll try to work on it in the next days. In the mean time, if you have some ideas that could improve developer experience or new features in mind let us know.

I see two things developers often suggest :

• make the current namshi/jose encoder bridge more flexible by handling the PHPSECLIB and allowing to choose from any algorythm handled by the library (https://github.com/namshi/jose/tree/master/src/Namshi/JOSE/Signer/OpenSSL)
• ease other jws library integration - maybe by providing local bridges implementing JWTEncoderInterface and adding those libraries to the suggest section of the composer.json ? In that case, the JWTEncoder class should be renamed also.

[chalasr]

@slashfan I'm going to start I started to work on integrating the phpseclib and make the algorithm used configurable.

As the encoder is already configurable, pretty much all the configuration work is done thanks to the lexik_jwt_authentication.jwt_encoder alias (used to replace service arguments by the configured encoder), developers just have to choose between the lexik_jwt_authentication.encoder.jose.open_ssl (default) and the lexik_jwt_authentication.encoder.jose.sec_lib (or another custom encoder).

For this, I moved the current JWTEncoder to a Encoder\JOSE\BaseEncoder then added the Encoder\JOSE\OpenSSLEncoder and Encoder\JOSE\SecLibEncoder sort as we can integrate different JWS libraries in the future.
I need to separate the JOSE encoders in two because the Namshi\JOSE\SimpleJWS supports only OpenSSL for now, and surely for other differences that I don't have the knowledge ATM (so I need to use Namshi\JOSE\JWS directly).
I use Namshi\JOSE\JWS for the two (I have a work in progress on Namshi\JOSE that would makes us able to use SimpleJWS for the two).

It would be nice if you can quickly review my feature_seclib_openssl_algos and give me your feedback.
It works well! The documentation need to be updated, if the whole implementation sounds good for you, I would like to have your suggestions about how to document the new features (the two new encoders + the several algorithms supported & configurable).

What do you think about this?

[slashfan]

@chalasr again, very good work you did here ! The only problem I see here is that the old JWTEncoder class is gone (which is necessary) so it could result in problems for developers who extend it or use it directly. It might be time to start a v2 branch while we work on the new (breaking) features.

[chalasr]

@slashfan Glad to see that my work is appreciated.

As you pointed, I re-added the JWTEncoder to keep compatibility, marked it as deprecated in phpDoc (maybe trigger an E_DEPRECATED?) in order to remove it in 2.0. That would let the time to developers to adapt their code by just use the OpenSSLEncoder.
I have to document and try to add functional tests.

Let me know if you think that this could be merged in 1.x so I open a PR on master, or if I wait for a 2.0 branch and totally remove the JWTEncoder.

Thank you!

[slashfan]

@chalasr It may be cleaner to keep this feature for version two. With proper documentation and testing. Don't you think ?

[chalasr]

@slashfan You're right, it's a major change so it needs a major release, and so avoid deprecations.
It would be good if you can create the 2.0 branch so I can quickly submit a PR and mark the task as in progress/done in the 2.0 todo list, then I could enchain on the next tasks.

Waiting for your green light.

[slashfan]

@chalasr Yes, before that I'd like to validate the workflow with you.

We create a new branch to work on and leave master untouched for fixes during the development of the v2 and its stabilization. We'll also add a corresponding branch alias in the composer.json so it can be used by easily by testers / early adopters.

How do we name the new branch ? v2, 2.x, 2.0, or simply develop ?

[chalasr]

I usually do "everything to master at first" and so having branches that represent stable releases.
But, as it surely would be easier to keep clean and because I totally trust you about the way to use it, let's go on.

However, when it'll be time to release the major v2.0.0 version, would we merge the new branch in master and so always keep master representing our last stable major version?

About naming the new branch, that's a really good question...
Naturally I would go on 2.x, but as we have a different branching model, and depending on your answer to my previous questions, what do you think about use 2.0?

It looks like nothing but it's an important decision as this next version represents a big step for the bundle.
Thank's to taking care of my opinion @slashfan

[slashfan]

@chalasr Sorry for the delay.

The idea is indeed to merge the new branch into master when it is stable enough and get rid of it afterwards. Maybe we can also create a 1.x branch before merging.

2.0 sounds good to me too. I'll create it right away.

[chalasr]

:+1:

[chalasr]

Reminder:
As pointed in #162 review and mentioned as best practice in the symfony doc, class parameters should be removed from Resource/config/services.xml in 2.0.

[slashfan]

@chalasr Added to the list of todo, thanks

[chalasr]

@slashfan Just to be sure, do we stop supporting Symfony 2.7 and lower versions in 2.x ? I had to make concessions in #162 to keep tests green, it would be interesting if we can avoid them.
If it's ok, I'll remove these versions from the travis configuration and quickly re-add the changes using features needing Symfony 2.8+

[slashfan]

2.8 / 3.0+ was the goal since the main idea was to use the Guard component. I know it can be used with 2.7 but it might be too much overhead to maintain 2.7 along with the other versions. What do you think ? @chalasr @weaverryan

[chalasr]

@slashfan Supporting 2.7 is possible ATM but could involve (too much) efforts and concessions as long as the bundle evolves. Our 1.x releases are here for that and so, if people want to take benefit of the newer features then they must up Symfony to 2.8 or higher.
As maintaining a 1.x branch should not be too hard, it seems to be a good compromise to me.

[weaverryan]

I'm ok with 2.8+ because it's an LTS and the "old" version of this bundle is still wonderful and will be useable on older versions.

[slashfan]

Good, 2.8+ it is !

[chalasr]

The v2 has been released. We are looking for feedbacks!
Closing as resolved

[Spomky]

Thank you so much @chalasr .
Beside this great news, I take the opportunity to announce you that you introduced in the #233 is now tagged as v1.0.0.
This means you can now use it with this new major release as a good alternative to the default encoder.

Thanks also for the references you added in the documentation. This is really kind of you.