-
Notifications
You must be signed in to change notification settings - Fork 71
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
Non-base64 decode-able authentication throws #40
Comments
In all the standard auth middlewares this is the pattern, which you can then handle via the AuthenticationFailed failed event. Given this can be an indication of concern I don't feel comfortable supressing it in such a way. |
I don't think the failure should be suppressed, but I don't think the middleware should be throwing an uncaught exception.
In this block of code from the handler, the |
Hmm @Tratcher any thoughts on how this should behave? |
Agreed, it's good to catch exceptions for bad data input like bad base64, log it, and convert it to an auth failure rather than an app exception. That catch-all is for unexpected failures. |
Darn it. OK, I'll see what time I have this weekend. |
OK all done and published in the 2.2.0 package. |
Confirmed working as expected. Thank you for your work! |
Description of the problem you are seeing
When the Authorization header has a value that is non-base64 decode-able, the middleware throws an exception that it does not handle.
What do you think should be happening?
The same thing that happens when invalid credentials are supplied - an AuthenticationFail result is returned.
What is actually happening?
An exception is thrown with the message "Failed to decode credentials : {non-decode-able credentials}".
My ConfigureServices() code
Steps to reproduce
Send a request with the header "Authorization: Basic abc"
The text was updated successfully, but these errors were encountered: