Callback should act like a Slim middleware. about slim-jwt-auth HOT 7 CLOSED

Or you can save the token into container. Although I do like the idea of adding decoded token contents into the $request itself.

$app = new \Slim\App();
$container = $app->getContainer();

$container["jwt"] = function ($container) {
    return new StdClass;
};

$app->add(new \Slim\Middleware\JwtAuthentication([
    "secret" => "supersecretkeyyoushouldnotcommittogithub",
    "callback" => function ($request, $response, $arguments) use ($container) {
        $container["jwt"] = $arguments["decoded"];
    }
]));

from slim-jwt-auth.

The reason why I do not like this approach is, that I would need to pass the whole DIC to my controller and I rather only pass the dependencies that are needed directly. Otherwise my class could pull out whatever out of there without anyone on the outside knowing.

On top of that this requires to pass the DIC to pretty much every controller (that handles a protected route, that is) :c

//EDIT: (Quick brainfart before bed)
Give your callback function the encoded and decoded token and let the user return something.
After the callback, assemble an array with the token, the decoded object and the callback result and attach this array under the key jwt_auth to the request. That way every affected route can access the token as well as the result of the callback function.

That way every user can access the token and decoded object the same way and has access to the arbitrary information of their callback under a given key in the jwt_auth array.

from slim-jwt-auth.

Can you check if fb8541c fixes your problem. I am still thinking about possibility of callback returning either false or [$request, $response].

from slim-jwt-auth.

Because I had to move my project forward, I wrote my own middleware that adds all the information I need to the request:

        // augment request object with data
        $jwt = [
            'token' => $tokenstr,
            'decoded' => $decoded,
            'account' => $account
        ];
        $augmentedRequest = $request->withAttribute('jwt', $jwt);

That being said:
Looking at your changes, you now add the token to the request, which is nice, however your callback function still does not allow me to add information like the user's account this token has been issued to, which I can resolve based on the "sub" property in the token.

Assuming I now have a "resolve Account by token" function somewhere (which I do) I would still in every route that needs the account information (e.g. for permission checks) to have to resolve this. That is still a lot of routes. Very much possible.

However, I still think it would be helpful for the user to attach additional information to the "attribute" that you are now supporting using the callback.

If you have a better suggestion how you would resolve my requirement, please go ahead, I would rather switch back to using your middleware :)

from slim-jwt-auth.

To me it sounds like what you are doing it outside of the scope of this middleware. It was never meant alter the request object, just authenticate and provide the decoded token. What happens after that is up to the developer. I think what you did is the correct solution, another middleware which does the authorisation part.

But like I said, I am still pondering about possibility of callback returning either false or [$request, $response]. I have not decided yet whether it is kludgish or not.

from slim-jwt-auth.

Well I am not asking for your middleware to "do these things".
I am asking you about what you imagine your callback function to do, and which options to open for the user?

Now that you have added the token to the request, the user gets a lot of more options and I could solve my problem with it.

But as the callback is right now, I do not see many use cases for it. There is no chance to really transport something out of the callback function unless you store it in a global place, which is usually a bad idea.

Middleware has access to the Request and Response and has the option to modify it. This is what you are offering. My suggestions above are mere suggestions that resolve my issue of "access to the token before it reaches the dispatched method and actually making the processing result accessible to every method that is protected by the middleware".

I do not really like the callback returning false [request, response] thing either. In Python its more natural to return tuples. Hence you can also return callback($request, $response, $next); and therefore give the user the chance to plug in their middleware logic and is forced to return $next($request, $response);

from slim-jwt-auth.

With 3.x branch you can currently do something like:

$app->add(new \Tuupola\Middleware\JwtAuthentication([
    "secret" => "supersecretkeyyoushouldnotcommittogithub",
    "before" => function ($request, $response, $arguments) {
        return $request->withAttribute("test", "test");
    }
]));

from slim-jwt-auth.