setToken (and possibly setRequest) return the previously logged in user
JwtGuard::setToken and JwtGuard::setRequest, if used in a long-running environment (a la octane etc, or a websockets server in my case) will not reset the user, but simply overwrite the token.
This leads to a behaviour where if there exists a cached user, and you reset the token, and call
$user = auth()->setToken('eyJhb...')->user();
# taken from official docs https://laravel-jwt-auth.readthedocs.io/en/latest/auth-guard/#set-the-token-explicitly
you will get the cached user, instead of the user represented by the new token.
Your environment:
| Q |
A |
| Bug? |
yes |
| New Feature? |
no |
| Framework |
Laravel |
| Framework version |
10.x |
| Package version |
2.7.§ |
| PHP version |
8.2 |
Steps to reproduce
In a loop, log in a user via setting the token, and then do it again with a new token, the user() method will return the original user.
Expected behaviour
setting a token should invalidate the user cache
Actual behaviour
setting a token returns the "previous" / "cached" user
setToken (and possibly setRequest) return the previously logged in user
JwtGuard::setToken and JwtGuard::setRequest, if used in a long-running environment (a la octane etc, or a websockets server in my case) will not reset the user, but simply overwrite the token.
This leads to a behaviour where if there exists a cached user, and you reset the token, and call
you will get the cached user, instead of the user represented by the new token.
Your environment:
Steps to reproduce
In a loop, log in a user via setting the token, and then do it again with a new token, the user() method will return the original user.
Expected behaviour
setting a token should invalidate the user cache
Actual behaviour
setting a token returns the "previous" / "cached" user