Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

lggomez
Copy link
Member

@lggomez lggomez commented Aug 3, 2021

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

@lggomez lggomez requested review from mfridman and oxisto August 3, 2021 22:44
}
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}
Copy link
Member

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.

Copy link
Collaborator

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.

Copy link
Member Author

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

Copy link
Collaborator

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.

Copy link
Member

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.

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())
Copy link
Member

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.

@oxisto oxisto changed the base branch from main to v5 December 9, 2022 18:32
@oxisto
Copy link
Collaborator

oxisto commented Feb 20, 2023

I incorporated the general idea and the test case into #274 for v5.

@oxisto oxisto closed this Feb 20, 2023
@oxisto oxisto deleted the feature/fix.75 branch March 27, 2023 17:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

jwt.Parse got "invalid character 'x' looking for beginning of value"
4 participants