esp-v2: Incorrect padding for X-Endpoint-API-UserInfo header
Per docs, the X-Endpoint-API-UserInfo header is supposed to be base64 encoded list of the original claims. However, an example value I received just now is of length 354 - which is missing == at the end.
Confirmed by using Python base64.decodebytes(user_info_encoded.encode()).decode() to decode which fails unless I add ==.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 21 (5 by maintainers)
I thought the library handled non-padding binary and automatically handle padding binary; didn’t expect some library expected strict padding/non-padding binary.
Worth to note the change is reverted on the upstream envoy and backported in the latest 1.18.3. I have another pending change to enable it by option.
Our next release pinning to 18.3 will change this behavior back and later we will expose this feature as a flag.
@nareddyt, you may put the revert in the note in our next release.
Thanks. I updated the release note.
I’m running into a similar issue with the Golang’s built-in base64 lib where decoding this header as base64 URL with or without padding was throwing errors. I solved it by trying to decode
base64.URLEncodingfirst, then falling back tobase64.RawURLEncodingbefore faulting.Some additional documentation to let users know of this inconsistency would be very helpful here!
Okay, looks like the RFC is unclear about whether padding is necessary or not for
base64url. In any case, looks like Python’s base64url decoder lacks support for relaxed checking of padding. I’ll just work around this in my code. Thanks!