-
Notifications
You must be signed in to change notification settings - Fork 361
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
jwt: Return better error messages on malformed tokens #84
Conversation
} | ||
if err = json.Unmarshal(headerBytes, &token.Header); err != nil { | ||
return token, parts, &ValidationError{Inner: err, Errors: ValidationErrorMalformed} | ||
return token, parts, &ValidationError{Inner: fmt.Errorf("malformed token header: %w", err), Errors: ValidationErrorMalformed} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been going back and forth on this one. The intention is good, but is it going to break existing users?
There is a lot to be desired in terms of improving errors. But is this something we should tackle in the current /v4
or punt to a breaking release /v5
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This discussion comes back to the point that we should discuss a common roadmap. I wonder, whether doing this in GitHub discussions is enough or if it makes sense to have a short zoom / Teams call on this to discuss a some roadmap ideas among the maintainers. Probably tricky to find a good time slot for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can opt to use semver properly in v4 and treat minor but non-revisional changes as these via releases (unless we strictly want to make the v4 release family v3 compatible). Those are the 2 options I see right now
@oxisto I think we can do fine with gh discussions for a middle ground between a chat and a an issue, for something more fluent we could use discord or something alike. I agree that coordinating a time slot might be difficult for a live conversation as we have tight schedules and different timezones but a chat server comes second place in communication efficiency so we can still gain something
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, maybe a discord server would be a nice idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can opt to use semver properly in v4 and treat minor but non-revisional changes as these via releases
Ye that's fair, since we are using modules we can bump minor versions and just make sure to jot that down in the release change log.
I'm not sure I have the bandwidth for in-person chats. Happy to continue contributing asynchronously, also there is nothing pressing afacis.
FWIW there is already a Gophers slack, and can create a "jwt" channel (maybe not) or just ping whoever is on there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The golang slack would seem like a obvious choice - many thousands of go users there and I believe they allow project channels.
t.Fatal("expected error") | ||
} | ||
if err.Error() != "malformed token payload: invalid character 'x' looking for beginning of value" { | ||
t.Errorf("unexpected error \"%s\"", err.Error()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit. can use %q to avoid escaping double quotes.
I incorporated the general idea and the test case into #274 for |
Fixes #75, as the jwt.io debugger also considers this payload invalid JSON and is validated as expected. the same applies to the other sections of the token