feat(electric): Try decoding the JWT key using base64 only when the config option is set #1168
Conversation
| @@ -72,6 +79,7 @@ defmodule Electric.ConfigTest do | |||
| validate_auth_config("secure", | |||
| alg: {"AUTH_JWT_ALG", "HS256"}, | |||
| key: {"AUTH_JWT_KEY", String.duplicate(".", 32)}, | |||
| key_is_base64_encoded: {"AUTH_JWT_KEY_IS_BASE64_ENCODED", false}, | |||
There was a problem hiding this comment.
we could just leave this explicit setting of this flag out to test the default behaviour, or add an explicit test for the default behaviour
There was a problem hiding this comment.
The default behaviour is to accept a string of sufficient length regardless of its encoding. This is already verified in the first assertion in this test, to the extent that the config with key_is_base64_encoded omitted from it is deemed valid.
The actual key decoding behaviour is tested in Auth.SecureTest.
We could already benefit from using a hierarchical configuration language like TOML. It'll become more pressing as we add more configuration options to Electric over time. |
This reverts the change introduced in the 0.9.3 release where the configured signing key would get automatically decoded if it looked like a valid base64-encoded string. That change has caused unintended problems to arise for users of Supabase Auth since its secret keys are base64-encoded but are meant to be used as is.
This PR introduces a separate configuration option
AUTH_JWT_KEY_IS_BASE64_ENCODED. Corresponding doc update - #1169.