HTTP 431 & Realtime Subscriptions Failing about realtime HOT 11 CLOSED

PR was merged! thank you @nbarrow-inspire-labs for the contribution 🙏

from realtime.

I've been researching and you are right. It seems like Keycloak cookies are pretty big.

https://keycloak.discourse.group/t/keycloak-cookies-are-too-large/15872
react-keycloak/react-keycloak#139
https://stackoverflow.com/questions/55955926/how-to-reduce-the-size-of-the-access-refresh-tokens-in-keycloak

I don't know if there is a way to make them smaller, but seems legit to increase the header limit in this case. Let's see what the members of the Supabase team thinks about #762 :)

from realtime.

Also, if this helps, I know there should not be a difference to using 127.0.0.1 versus localhost. The issue is that the API I'm trying to integrate with uses OAuth 2.0 and they do not allow IP Addresses for valid/approved redirect URIs, so I can only use localhost and not 127.0.0.1.

The idea is my app needs to be running on the same URL for Supabase Auth to work, but that URL also needs to work with my external OAuth tool (which restricts me to just localhost).

from realtime.

In my `` logs, I can confirm:

2023-12-16 21:32:32 192.168.48.1 - - [17/Dec/2023:02:32:32 +0000] "GET /realtime/v1/websocket?apikey=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6ImFub24iLCJleHAiOjE5ODM4MTI5OTZ9.CRXP1A7WOeoJeXxjNni43kdQwgnWNReilDMblYTn_I0&vsn=1.0.0 HTTP/1.1" 431 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36"
2023-12-16 21:32:36 192.168.48.1 - - [17/Dec/2023:02:32:36 +0000] "GET /realtime/v1/websocket?apikey=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6ImFub24iLCJleHAiOjE5ODM4MTI5OTZ9.CRXP1A7WOeoJeXxjNni43kdQwgnWNReilDMblYTn_I0&vsn=1.0.0 HTTP/1.1" 431 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36"
2023-12-16 21:32:39 192.168.48.1 - - [17/Dec/2023:02:32:39 +0000] "GET /realtime/v1/websocket?apikey=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6ImFub24iLCJleHAiOjE5ODM4MTI5OTZ9.CRXP1A7WOeoJeXxjNni43kdQwgnWNReilDMblYTn_I0&vsn=1.0.0 HTTP/1.1" 431 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36"
2023-12-16 21:32:42 192.168.48.1 - - [17/Dec/2023:02:32:42 +0000] "GET /realtime/v1/websocket?apikey=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6ImFub24iLCJleHAiOjE5ODM4MTI5OTZ9.CRXP1A7WOeoJeXxjNni43kdQwgnWNReilDMblYTn_I0&vsn=1.0.0 HTTP/1.1" 431 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36"
2023-12-16 21:32:46 192.168.48.1 - - [17/Dec/2023:02:32:46 +0000] "GET /realtime/v1/websocket?apikey=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6ImFub24iLCJleHAiOjE5ODM4MTI5OTZ9.CRXP1A7WOeoJeXxjNni43kdQwgnWNReilDMblYTn_I0&vsn=1.0.0 HTTP/1.1" 431 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36"

from realtime.

Additional Context and my best guess of what is going on:

• this only started when I moved from local storage to cookie-based storage of access tokens for SSR and the @supabase/ssr package
• it looks like this caused the cookies to now be sent in the websocket request, greatly increasing the payload size (compared to no cookies)
• the cookies increase size so much that the websocket fails (due to Kong)

from realtime.

Hi @nbarrow-inspire-labs, by default, Phoenix limits the size of the headers to 4KB (reference), which is not a big size if you have several cookies. You will likely reach that limit if several services run on the same domain and the path is not scoping your cookies. If you are working locally on different projects, all those cookies will be stored at 127.0.0.1 and it is easy to reach that limit.

Can you share a screenshot of the size of all the cookies you have on the domain you are having trouble with?

You can check it in the Chrome DevTools under the application tab

from realtime.

Maybe you can change the configuration to allow bigger headers in your app. I think you just have to change the config/config.exs file with these changes:

# Configures the endpoint
config :realtime, RealtimeWeb.Endpoint,
  # ...
  http: [
    port: System.get_env("PORT", "4000"),
    protocol_options: [max_header_value_length: 8192] # <-- this will duplicate the size of the header's limit
  ]

from realtime.

@gabrielperales thanks for getting back to me. I think you're right, the size is just larger than the 4kb maximum (see screenshot below). I'm experiencing this issue using the supabase CLI but also the self-hosted docker compose example. Do you know if setting an environment variable will configure max_header_value_length? Edit: would something like this do: #762 ?

from realtime.

@gabrielperales would something like this work: #762

from realtime.

@gabrielperales would something like this work: #762

It worked for you, so yes :). But I would check why those cookies are so big and why you have those two rather than change the configuration. Anyway, I don't see any problem with having the option to overwrite that limit, but first, check what you are storing in those cookies and if everything is needed.

If the answer is yes, then you will need to overwrite.

You probably store the whole user profile in the cookie session and don't need to do that.

from realtime.

But I would check why those cookies are so big and why you have those two rather than change the configuration. Anyway, I don't see any problem with having the option to overwrite that limit, but first, check what you are storing in those cookies and if everything is needed.

@gabrielperales I did look at the cookies; there are two of them, both set by Supabase. One seems to be from my auth provider configured through Supabase (Keycloak) and the second seems to be a direct Supabase token. I.e., one is to authenticate between the client and Supabase, and one seems to be for Supabase to refresh itself against my Keycloak instance.

from realtime.