-
Notifications
You must be signed in to change notification settings - Fork 381
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
LoginHandler assumes type of error from Authenticator #265
Comments
I just noticed in option 1 that this only works as long as the errors have static messages. For dynamic errors where the message string may be different, it becomes difficult to detect in the |
Up ! Just been through this issue while using your middleware. Does something is plan for that ?
struct return {
code: *int;
payload: interface{} // (current return)
}
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following is the snippet of code from line 437-442 in auth_jwt.go, within the LoginHandler function:
The snippet shows that the login handler assumes that if the Authenticator function returns an error, that the code to return to the client is a 401 (Unauthorized) error. The Authenticator function may be accessing a database of users, and that connection may experience issues where a 500 error would be the correct error to return to the client.
This is not a blocking issue since workarounds exist. Here are a couple of workarounds I could think of:
Option 1:
This option feels clunky and doesn't scale well if there are more types of errors.
Option 2: Provide our own LoginHandler function. This option is not desirable because there is a lot of good stuff in the LoginHandler function provided by gin-jwt.
Maybe there is a 3rd option to return the correct status code to the client when internal errors occur?
Version: 2.6.4
The text was updated successfully, but these errors were encountered: