fix: override max_header_value_length using environment variable#762
Conversation
Solves #761 by introducing an environment variable to override config -> http -> protocol_options -> max_header_value_length or leaves it at the default 4096 if no other value is specified
|
@nbarrow-inspire-labs is attempting to deploy a commit to the Supabase Team on Vercel. A member of the Team first needs to authorize it. |
max_header_value_length using environment variable
|
I did test-build this locally and it 100% fixed the issue with Edit: you should not need to set these Kong variables (for docker compose with |
|
@filipecabaco when you have a chance, can you take a look at this? It seems partially related to #746 which you helped me with a week or so ago. This should fully solve the rest of the problem (#761). |
|
Hey! just a FYI that I will take a look later today 👁️ |
|
Just wanted to see if anyone's had the chance to take a look at this yet? It should be a pretty quick review (hopefully!) |
|
not yet sorry... 😓 tricky week. there's one change needed in the mix.exs file to bump the minor version to (2.25.50) and will check the remainder of the code now |
|
yep looks good, just needs that change in the mix.exs to 2.25.50 since I'm going to merge 2.25.49 now |
|
@filipecabaco awesome (and no worries on the delay!) thanks for checking. I just bumped the version in |
|
going to rebase and merge to fix the conflict. thank you for the help 🙏 |
|
Appreciate the help, thanks @filipecabaco ! |
|
🎉 This PR is included in version 2.25.50 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
What kind of change does this PR introduce?
Bug fix for #761:
MAX_HEADER_LENGTHthat can be used to override config -> http -> protocol_options -> max_header_value_length from its default value in Elixr (4096)What is the current behavior?
With SSR and the use of cookies to authenticate on the server, all cookies need to be sent to Supabase requests, including Realtime. If these cookies exceed the (rather low) default of 4096 (which, with an auth provider for supabase, can happen extremely easily), realtime subscriptions fail with a 431 error.
Edit: we are using Keycloak as our Supabase authentication provider, and it looks like Keycloak is a bit notorious for large cookies (see #761 (comment)). Hence the further need to increase the limit, but in a dynamic fashion (for users who wish to retain the security benefits of smaller limits and don't use Keycloak or other services with larger cookies).
What is the new behavior?
With the new behavior, a user could specify a
MAX_HEADER_LENGTHenvironment variable to a higher value (such as8192, doubling the limit) to cease the 431 errors.Additional context
See #761
Edit: I test-built with these changes locally and it 100% fixed the issue.