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

Get request in error callback - 3.x #96

Open
X-Tender opened this issue Feb 16, 2018 · 7 comments
Open

Get request in error callback - 3.x #96

X-Tender opened this issue Feb 16, 2018 · 7 comments

Comments

@X-Tender
Copy link

I try to implement following behaviour:

  1. User visit a page route which required authentification/valid token.
  2. user have no valid token so error callback jumps in
  3. 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);
  4. User logs in
  5. 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?

@tuupola
Copy link
Owner

tuupola commented Mar 2, 2018

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));
    }
]));

@X-Tender
Copy link
Author

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)

@IlyaKochetov
Copy link

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.

@taraldr
Copy link

taraldr commented Sep 21, 2018

I too would love to see the Request available in the error callback 👍

@tuupola tuupola added the 4.x label Dec 22, 2018
tuupola added a commit to tuupola/branca-middleware that referenced this issue Feb 1, 2019
tuupola added a commit that referenced this issue Feb 24, 2019
This is a workaround because changing the error handler signature would
break BC. Removing the request in 3.x was an oversight on my part and
it will most likely be put back in 4.x.
@tuupola
Copy link
Owner

tuupola commented Feb 24, 2019

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?

@X-Tender
Copy link
Author

I think this is OK until 4.0

@Mikk3lRo
Copy link

Mikk3lRo commented Mar 6, 2019

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.

tuupola added a commit that referenced this issue Mar 10, 2019
* Pass request uri as an argument to error handler 

This is a workaround because changing the error handler signature would
break BC. Removing the request in 3.x was an oversight on my part and
it will most likely be put back in 4.x.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants