Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong remaining minutes when blacklisting a token #2250

Open
mohph197 opened this issue Mar 23, 2024 · 4 comments · May be fixed by #2251
Open

Wrong remaining minutes when blacklisting a token #2250

mohph197 opened this issue Mar 23, 2024 · 4 comments · May be fixed by #2251

Comments

@mohph197
Copy link

Subject of the issue

When invalidating a token, an amount of minutes is calculated to specify how much the token should stay in the Blacklist
The problem is in the way it's calculated seems wrong, at least in my case it was wrong it just needs to be turned to positive before returning, and also for some reason the "diffInRealMinutes" Carbon method is used, I didn't find it anywhere in Carbon's actual Doc

Your environment

Q A
Bug? yes
New Feature? no
Framework Laravel
Framework version 11.0.7
Package version 2.1
PHP version 8.2.12

Steps to reproduce

Try logging in with the login, and then using the refresh route

Expected behavior

Here the token from login should be invalidated by default
So you should expect a new entry in the cache table in the database (if all the configurations are exactly as the defaults of Laravel 11.x)

Actual behavior

No entry is introduced, and the token is still valid (you can actually perform many consecutive calls to refresh with the same token)

@mohph197 mohph197 linked a pull request Mar 23, 2024 that will close this issue
@amir-khoshbakht
Copy link

amir-khoshbakht commented Mar 24, 2024

It also breaks the logout functionality

@amir-khoshbakht
Copy link

amir-khoshbakht commented Mar 24, 2024

..... the "diffInRealMinutes" Carbon method is used, I didn't find it anywhere in Carbon's actual Doc
https://github.com/briannesbitt/Carbon/blob/34ccf6f6b49c915421c7886c88c0cb77f3ebbfd2/src/Carbon/Traits/Date.php#L2595

the "diffInRealMinutes" is the same as "diffInMinutes"

@elhannaoui-ayoub
Copy link

please how does the token invalidate works , do we store them in a table of balcklists or what?

@francsiswanto
Copy link

francsiswanto commented May 2, 2024

This is my solution and it's work.

  • Create some providers to override existing Tymon\JWTAuth\Providers\Storage\Illuminate, let say name it as 'App\Storage\JWTStorage'. See script below.
  • Publish jwt configuration
  • Edit config/jwt.php and replace 'providers' as
(-) 'storage' => Tymon\JWTAuth\Providers\Storage\Illuminate::class,
(+) 'storage' => App\Storage\JWTStorage::class,

App\Storage\JWTStorage.php script:

namespace App\Storage;

use Tymon\JWTAuth\Providers\Storage\Illuminate;

class JWTStorage extends Illuminate {
    public function add($key, $value, $minutes) {
        parent::add($key, $value, abs($minutes));
    }
}

Since blacklisting/invalidating using cache mechanism, then artisan cache:clear will erase all blacklist entries. To avoid it, we can tweak above script to targeting into another store (example 'redis_blacklist'):

use Illuminate\Contracts\Cache\Repository as CacheContract;
use Tymon\JWTAuth\Providers\Storage\Illuminate;

class JWTStorageProvider extends Illuminate {
    protected $cache;

    public function __construct(CacheContract $cache) {
        $this->cache = cache()->store('redis_blacklist');
    }

    public function add($key, $value, $minutes) {
        parent::add($key, $value, abs($minutes));
    }
}

of course the solution above is better solved by jwt-auth, including changing the use of blacklist storage with config/jwt.php.

Just simply do the best, hoping for the best and let God take the rest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants