slim-jwt-auth
slim-jwt-auth copied to clipboard
Get request in error callback - 3.x
I try to implement following behaviour:
- User visit a page route which required authentification/valid token.
- user have no valid token so
errorcallback jumps in - I redirect the user to the login form
(At this point I would like to get the URL the user tries to access and store it via a flash message for example )
return $response->withRedirect($container->get("router")->pathFor("login"), 301); - User logs in
- I see that the user tried to access an another page (from the flash message) and redirect him to the path
The problem is that I can't access the Request from the error callback and the before callback is only called when a token can be found and decoded.
Any suggestions how this can be achieved?
Good question. This seems to be one use case I did no think about. Kludgish way would be to store the current url in another middleware for the error callback. Better way would probably be if I added the current url to the $arguments array.
$app->add(new Tuupola\Middleware\JwtAuthentication([
"secret" => "supersecretkeyyoushouldnotcommittogithub",
"error" => function ($response, $arguments) {
$url = $arguments["url"]; // Do something with the url
$data["status"] = "error";
$data["message"] = $arguments["message"];
return $response
->withHeader("Content-Type", "application/json")
->write(json_encode($data, JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT));
}
]));
Currently I do the middleware dance like you proposed. 😄 Wouldn't it be easier to pass the request to the error callback too? (Like in V2)
Ideally the request should be added to the error callback. There seems to be no reason why it shouldn't and the code seems to be working fine if I hack the change in.
I too would love to see the Request available in the error callback 👍
Changing the error handler signature would be a BC break. Putting $request back there as it was would require major version bump. It is my plan in near future, but in the meanwhile would #155 an acceptable workaround?
I think this is OK until 4.0
I was about to post the same issue, but will leave a +1 for this instead.
My use case is different, as I don't need the URL, but the accept-header from the request - to correctly format an API-response (JSON / XML).
I can easily come up with a workaround (#155 doesn't solve my issue), but I feel like the "correct" way would be to have the request available. There are probably many other scenarios.
...just noticed the pull request regarding this: #141.