Validate token passed in query parameters same as headers

[bhavikkumar]

Validates access tokens passed through query parameters in the same manner as if they were passed in Authorization HTTP header as a bearer token.

This resolves #7011

[bhavikkumar]

I've made the assumption that the query parameters here have already been decoded and therefore can be validated against a pattern.

If this is not true then just checking for empty query parameter will also resolve the issue.

[jzheaux]

Thanks, @bhavikkumar, for the PR! I've left some feedback inline.

[jzheaux]

Also, @bhavikkumar, would you please format your commit message like this, including at least the phrase "Fixes: gh-7011"?

[bhavikkumar]

@rwinch Fixed the reactive flow in #7020

[jzheaux]

@bhavikkumar, in taking another look at this PR and matching it against the RFC, I think there's a mismatch since the RFC doesn't specify a format for bearer token query parameters. I think it would be better to stick to the RFC, and, in fact, #7020 aligns with this on the reactive side.

So, to better align with the RFC and also the reactive solution of #7011, would you please update your PR to complain when the query parameter is empty (not if it doesn't follow the same pattern as a bearer token header value)?

[bhavikkumar]

I just wrote a quick test around this for the non reactive flow, it seems to work as expected. Closing this PR.

[jzheaux]

@bhavikkumar, sorry, I'm confused. #7020 only addresses the reactive stack. I think your PR is still necessary for the servlet stack?

[bhavikkumar]

I had not verified the servlet stack, but based on the code it looked like it needed the same fix. However, when I implemented it to check, it worked fine without the fix. I received the expected 401 response.

I didn't follow it through to where it was being handled. I can push up the example if you want to verify.

[jzheaux]

I see, @bhavikkumar, thank you.