Hi
For a specific use case we would like to change the header from Authorization to JWTAuthorization. We are working in an environment that hijacks the Authorization header thus disabling us to use this package since the token gets overwritten. Would you considering this if we supplied a PR?
Extending the request: We are using Basic auth (in this case via nginx) to secure a staging site. But the implementation of JWT overwrites the Basic auth header with the Bearer token.
Therefore each requests returns a 403: unauthorized in nginx.
Ok, so issue https://github.com/tymondesigns/jwt-auth/issues/560 is a possible solution. However, I think it would still be interesting to be able to change this params globally through the config file.
Let us know what you think.
Yeah if you're using v0.5, you can use the solution in that issue.
In 1.0.0, you can configure this, although you have to do it through the parser setup and not just a config file change. If headers are the only thing you care about checking, it goes something like this:
$headerParser = new \Tymon\JWTAuth\Http\Parser\AuthHeaders;
$headerParser->setHeaderName('JWTAuthorization'); // though HTTP headers are case-insensitive so case shouldn't matter
JWTAuth::parser()->setChain([$headerParser]);
If you want the rest of the default parsing chain's fallbacks, like query strings & route parameters, you'll have to put them in yourself. (You could technically edit the existing chain, but since it's an unkeyed array it's easier to just make a new one.)
Though if you want this globally though the app, it should probably be done with a service provider. You can look at how it's already done in the LumenServiceProvider for an example. Just replace the AuthHeaders bit with the configured instance like I showed above.
Most helpful comment
Yeah if you're using v0.5, you can use the solution in that issue.
In 1.0.0, you can configure this, although you have to do it through the parser setup and not just a config file change. If headers are the only thing you care about checking, it goes something like this:
If you want the rest of the default parsing chain's fallbacks, like query strings & route parameters, you'll have to put them in yourself. (You could technically edit the existing chain, but since it's an unkeyed array it's easier to just make a new one.)