jwt-auth
jwt-auth copied to clipboard
tymondesigns
PHP8 & lcobucci/jwt 4 compatibility
This PR addresses #2088, #2082, #2103 and probably others. It probably supersedes #2073 which does not include all required changes to update lcobucci/jwt to v4.x. Also relates to topics mentioned under #2059.
Existing tests are updated and pass, and I've also tried some basic use-cases. You can see 3 fixes in the gitlog. The "funny" thing is that those serious issues were not indicated by any automated tests. Probably it would be best to make some tests that check if the tokens are generated with the right content and validated properly, instead of only checking if mocked methods are being called. That being said, I cannot spend more time on this, so I'll leave it up to others.
Please note I'm not a security expert, so review before using this for anything serious!
+1. This package is starting to conflict with other packages using version v4.x of lcobucci/jwt
Github is not allowing me to run the workflow/tests for this right now due to a 500 error. I will check back later to see if it's resolved. I may end up just re-creating the PR if I need to
@tymondesigns any update about this, I'm using PHP8 and I'm using another library that require version 4 of lcobucci/jwt so there is no chance to install both packages right now, if this pull merged it will save me a lot of time, Thank you for your effort
I've made a temporary fork until this PR is merged and submitted it to Packagist. Might be useful for other people here.
composer require dees040/jwt-auth
Well I really hope he's OK and healthy.
Just saying because I tried to contact through LinkedIn and there was no answer, also his Twitter has been dead for a while…
Well I really hope he's OK and healthy.
Just saying because I tried to contact through LinkedIn and there was no answer, also his Twitter has been dead for a while…
He is alive! Please look at the github profile activity
For those that can, I'd suggest migrating to https://laravel.com/docs/master/sanctum or https://laravel.com/docs/master/passport
@tymondesigns has put a lot of work into this library to solve a problem that existed in 2016 (5-6 years ago) and like everybody else we thank him for his time and effort. Even though this project is sponsored by auth0 I don't think they are paying him enough to dedicate more time to it. It doesn't make much sense to provide updates/support when there are official libraries that will give you the same functionality.
Giving the project to another maintainer on 99% of the cases is not an option as the person taking over would have to be trusted.
For those that can, I'd suggest migrating to https://laravel.com/docs/master/sanctum or https://laravel.com/docs/master/passport
@tymondesigns has put a lot of work into this library to solve a problem that existed in 2016 (5-6 years ago) and like everybody else we thank him for his time and effort. Even though this project is sponsored by auth0 I don't think they are paying him enough to dedicate more time to it. It doesn't make much sense to provide updates/support when there are official libraries that will give you the same functionality.
Giving the project to another maintainer on 99% of the cases is not an option as the person taking over would have to be trusted.
Ok, but in this case that's a good solution, it's good for @tymondesigns to leave another maintainer to help him merge the PR's opened.
Read through the code and looks well handled, also tested successfully on local.
@tymondesigns please can you find another(s) maintainer(s) for this repo? The issues and evolution are taking too long.
Read through the code and looks well handled, also tested successfully on local.
@tymondesigns please can you find another(s) maintainer(s) for this repo? The issues and evolution are taking too long.
Agreed, totally understand how draining it can be to run an open source project @tymondesigns, so no worries, but we would like to lift some weight off your shoulders in order to keep this going.
I already send an email to him asking about this situation and see how can we support him, otherwise will be hard to keep this going.
Best Regards,
Fabio William Conceição
Remote: https://remote.com/fabiowilliam https://remote.com/fabiowilliam Tel/Whastapp: +351 93 212 1477 Skype: fabioo.william.conceicao LinkedIn: https://www.linkedin.com/in/fabio-william-concei%C3%A7%C3%A3o-379b9823/ https://www.linkedin.com/in/fabio-william-concei%C3%A7%C3%A3o-379b9823/ *Github: *https://github.com/Messhias/ https://github.com/Messhias/ Upwork: https://www.upwork.com/o/profiles/users/_~0126d10487b9843f68/ https://www.upwork.com/o/profiles/users/_~0126d10487b9843f68/
Em qua., 14 de jul. de 2021 às 20:34, dir @.***> escreveu:
Read through the code and looks well handled, also tested successfully on local.
@tymondesigns https://github.com/tymondesigns please can you find another(s) maintainer(s) for this repo? The issues and evolution are taking too long.
Agreed, totally understand how draining it can be to run an open source project @tymondesigns https://github.com/tymondesigns, so no worries, but we would like to lift some weight off your shoulders in order to keep this going.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tymondesigns/jwt-auth/pull/2117#issuecomment-880155087, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI3QQ2MGP2ZSEIBNOXVT3TTXXRFBANCNFSM43YDFBXA .
It's been 6 months, I hate to do this, but... fork inbound? This library has to do with security, and we can't go 6 months without a PR.
I don't have time to manage this, but would be willing to help out. cc @Messhias @BenceSzalai
I am happy to help when and where I can, and this applies to this repo as well as to forks, however I assume forking such a popular library would need wide community consensus and I'm certainly not the guy to build that out. On the other hand as each PR belongs to a fork, I see no problem if someone starts to collect reasonable changes and updates and others use those even maybe directly from github instead of packagist as a temporary solution. But encouraging people to switch completely may be a delicate topic, for many reasons but especially when we are talking about security related libraries. Correct me if i'm wrong, i'm just thinking out loud...
Edit: Also @tymondesigns reacted to this but he got 500 errors and would probably come back later, so while the 6 months assessment may be true, it's not like the original maintainer would have disappeared completely!
Hopefully he will appoint some other maintainers if he's schedule stays too tight for the foreseeable future.
I am happy to help when and where I can, and this applies to this repo as well as to forks, however I assume forking such a popular library would need wide community consensus and I'm certainly not the guy to build that out. On the other hand as each PR belongs to a fork, I see no problem if someone starts to collect reasonable changes and updates and others use those even maybe directly from github instead of packagist as a temporary solution. But encouraging people to switch completely may be a delicate topic, for many reasons but especially when we are talking about security related libraries. Correct me if i'm wrong, i'm just thinking out loud...
Edit: Also @tymondesigns reacted to this but he got 500 errors and would probably come back later, so while the 6 months assessment may be true, it's not like the original maintainer would have disappeared completely!
Hopefully he will appoint some other maintainers if he's schedule stays too tight for the foreseeable future.
I'm helping in the best way I can do too since I'm already in the Unreal Engine open source too trying to help, but the whole point of the topic and those PR's start being old is because the library is still a solo maintainer.
And about changing, you're totally right in the case of this library because if you see there's already a wide developer using it, if you type "laravel JWT package" on google this library it's the ones show first, there's a plenty tutorial using it. So the best way to keep doing some work with consistency is @tymondesigns to take at least 4 more maintainers or at least 2, keep it going (even in a smoothy and slow way), and start-stop the gap of months between an acceptance of a PR to another.
Any chance to get the new release with PR?
HAHAHHAHAHAHHAHAHAHAHAHHAHAHAHAHHAHAHAHHAHAHAHAHAHHAHAHAHAHHAHAHAHHAHAHAHAHAHHAHAHAHAHHAHAHAHHAHAHAHAHAHHAHAHAHAHHAHAHAHHAHAHAHAHAHHAHAHAHAHHAHAHAHHAHAHAHAHAHHAHAHAHAHHAHAHAHHAHAHAHAHAHHAHAHAHAHHAHAHAHHAHAHAHAHAHHAHAHAHAHHAHAHAHHAHAHAHAHAHHAHAHAHAHHAHAHAHHAHAHAHAHAHHAHAHAHAHHAHAHAHHAHAHAHAHAHHAHAHAHAHHAHAHAHHAHAHAHAHAHHAHA
Hi guys,
I was facing the same problems with lcobucci/4 incompatibility + Socialite Apple Provider requirements etc... After some time i figured that this library has pretty much no activity at all. I don't mean any disrespect to @tymondesigns. He's done a GREAT job and many thanks to him for everything but I think that now it's time to move on (at least we decided that in our company where we have multiple ongoing Laravel projects that use API auth).
So, I've decided to build a package of my own that handles JWT auth for Laravel apps => https://github.com/rcerljenko/laravel-jwt
Package highlights:
- Latest Google Firebase powered JWT backend library
- Minimum dependeny footprint (only latest Laravel and Firebase)
- Simple JWT configuration and use (config file + trait)
- No middlewares, facades, etc... just plain and simple config file, auth guard and trait.
Who should use this package?
- People that need to move on for techincal reasons from this package (like we had to in my company)
- People who expect that library follows latest Laravel and other dependency updates
- People who are willing to help in future development by discussing and sending PRs
As I said, we already use this in our company on production projects and it looks stable, safe and it doesn't stops us from installing some packages that we couldn't before.
Feel free to at least take a look and give some smart insight!
Cheers!
Hi guys,
I was facing the same problems with
lcobucci/4incompatibility + Socialite Apple Provider requirements etc... After some time i figured that this library has pretty much no activity at all. I don't mean any disrespect to @tymondesigns. He's done a GREAT job and many thanks to him for everything but I think that now it's time to move on (at least we decided that in our company where we have multiple ongoing Laravel projects that use API auth).So, I've decided to build a package of my own that handles JWT auth for Laravel apps => https://github.com/rcerljenko/laravel-jwt
Package highlights:
- Latest Google Firebase powered JWT backend library
- Minimum dependeny footprint (only latest Laravel and Firebase)
- Simple JWT configuration and use (config file + trait)
- No middlewares, facades, etc... just plain and simple config file, auth guard and trait.
Who should use this package?
- People that need to move on for techincal reasons from this package (like we had to in my company)
- People who expect that library follows latest Laravel and other dependency updates
- People who are willing to help in future development by discussing and sending PRs
As I said, we already use this in our company on production projects and it looks stable, safe and it doesn't stops us from installing some packages that we couldn't before.
Feel free to at least take a look and give some smart insight!
Cheers!
I almost changed to your package, but I don't see the reason for firebase be mandatory.