Base64-encoded bytestring required to be padded

[mcaldas]

Environment

• PostgreSQL version: GCP hosted, version 14
• PostgREST version: (if using docker, specify the image)
• Operating system: Linux

Description of issue

We are getting the following error sending the PGRST_JWT_SECRET encoded in base64: user error (Base64-encoded bytestring required to be padded). tried v9.0.1 and v9.0.1.20220717 both with same outcome. Worth noticing that if we send it not encoded everything works correctly.

Thanks, Mathias

[laurenceisla]

To handle base64 encoded secrets, it also needs PGRST_JWT_SECRET_IS_BASE64 set to true for it to work. Was that configuration enabled?

[mcaldas]

Hey! Yes indeed, thought it was needless to mention. When we send encoded we set to true and when we send plain we set to false

[laurenceisla]

Oh, then maybe the padding character is missing at the end? Adding = to the end of the string may solve the issue. When I delete it, I get the same error you mention.

[mcaldas]

Our secret already ends with '=', do you think we should add another? Thing is this same secret in a lot of other places without any issue. Also was being used in version 5 without a problem

[laurenceisla]

Then, maybe try encoding your secret again and update it in the configuration. Perhaps the length it's not a multiple of "4", it throws that error when it's not, according to the library: https://github.com/haskell/base64-bytestring/blob/master/Data/ByteString/Base64/Internal.hs#L146

[mcaldas]

Hey, you are right, the length is not multiple of 4, but because of the last "=", which counts 65. The thing is that any decode tool decodes it correctly. And if I re-encode it I get the same result. Should I try without the =?

[laurenceisla]

Ah, then yes. Using the secret without = at the end should do it.

[wolfgangwalther]

So it seems like the secret had padding - but too much. "invalid padding" that is.

The error message we throw indicates, however, that the padding is missing: user error (Base64-encoded bytestring required to be padded)

While the error message you linked to above, @laurenceisla, is: Base64-encoded bytestring is unpadded or has invalid padding.

Where is the error message changed?

We should fix that, either here our upstream, because the "invalid padding" part is lost in translation...

[laurenceisla]

@wolfgangwalther Right, I wasn't clear in that regard. I reproduced this using a Base64 JWT with 64 characters and adding two padding characters (==) at the end. These were the results:

• Version v9.0.1 gives the Base64-encoded bytestring required to be padded error.
• Version 9.0.1.20220717 (and up) gives the Base64-encoded bytestring is unpadded or has invalid padding error.

I used the second one to debug this as it was also mentioned in the OP.

[wolfgangwalther]

Ah, that makes sense. So it seems like the error message has been improved upstream already - nothing more to do for us here. Therefore I'll close. Please re-open, in case I misunderstood.