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

Timestamps in year 0000 are accepted as query parameters #4967

Closed
jakec-github opened this issue Nov 19, 2024 · 3 comments · Fixed by #4973
Closed

Timestamps in year 0000 are accepted as query parameters #4967

jakec-github opened this issue Nov 19, 2024 · 3 comments · Fixed by #4973

Comments

@jakec-github
Copy link
Contributor

jakec-github commented Nov 19, 2024

🐛 Bug Report

Affects APIs with a google.protobuf.Timestamp field on a GET request.

When grpc-gateway parses the timestamp query parameter it does return an error for dates in the year 0. This is inconsistent with the behavior described in the well known type test and with the behavior implemented in protojson.

Parsing of the timestamp field is done here

I am happy to submit a fix and include tests for min/max timestamp if this bug is considered an issue.

Seen in v2.19.1

To Reproduce

  1. Define an API that uses google.protobug.Timestamp as a field on a GET request
  2. Make the request with 0000-01-01T00%3A00%3A00.00Z
  3. See that this does not cause an error

Expected behavior

Should return a 400 Bad Request error

Actual Behavior

Request is accepted

Your Environment

N/A

@johanbrandhorst
Copy link
Collaborator

Thanks for the issue, that does seem wrong! Should we perhaps just add a t.IsValid() check after the creation of the type? Would be happy to see a PR.

@jakec-github
Copy link
Contributor Author

Thanks for merging! Will there be a patch release with this fix?

@johanbrandhorst
Copy link
Collaborator

Yeah we've had a bunch of changes in the last week, I'll tag a release soon!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants