usefulteam
Plugin does not return an error if invalid access token is supplied
When the whitelist was removed from the plugin, we also removed any functionality to return an error if a supplied access token is no longer valid.
In some scenarios, this can result in errors back from the WP REST API that don't describe what the real issue is with the request, for example a request like the following with an expired JWT:
/wp-json/wp/v2/posts?status=private
Will return an error that status is not a valid field, since it isn't depending on your user role or, as in this case, if you are not logged in.
In my case, I need to receive the jwt error, so that I can take action, e.g. log a user out on a UI.
I came up with this method:
Which is that for missing or malformed headers, we pass the request on, but for anything else we return the error.
Welcoming thoughts on this approach, some thoughts of mine:
- We could allow plugin users to toggle this behaviour with a filter
- We could allow plugin users to filter a list of codes that they want to return an error / skip returning an error
- If we're happy with these two codes, are there others...
I left a comment on https://github.com/dominic-ks/jwt-auth/commit/e55d3841c2d9a39b20c47cadeacdffe58ceb25a6#r162745324
But with the concrete case mentioned in the issue summary, I suspect it's actually outside of jwt-auth's territory. The REST request method/parameters validation happens very early in the REST router, and this is where the error is generated.
I'm actually surprised that jwt-auth even gets a chance to process the request at all, because the definition of REST endpoints in the server is not going to change depending on whether you are authenticated or not.
Yes, I missed a part as I needed to copy and paste it in, responded to your comment.
Yes the definition doesn't change, but a request to /posts as in my example, is available to all users, logged in or not. So, there is no point in this request where the user will be denied access due to not being logged in. However, WP will validate the query params later and will deem it invalid for a non-authenticated user.
But generally any issues with putting this in, perhaps with a filter to activate this behaviour so as not to affect people relying on their request falling back to another auth method in this scenario?