The above Discourse cookie string is 1,962 characters long!
For comparison, the cookie header sent to my Mediawiki site is 122 characters long, including my username, user id, and session id.
The Mediawiki session id is 32 characters long, but Discourse appears to have two session ids: rack.session is 813 characters long and _forum_session is 1,075 characters long. Please help me to understand why a simple uid needs to be so long. Can I configure Discourse to use a shorter session uid? Does such a request make sense?
What is stored in that string? Is it possible to make it smaller?
Specifically, what component of the Discourse software is rack.session used for? And what is _forum_session used for?
Of course I can just bump up the nginx config limits, but I’d like to keep them reasonably low unless there’s a strong requirement to increase them.
I support auditing our session cookies and maybe just moving to default use our redis backed session that auto expires which is better anyway. @david any thoughts here?
Depends, plugins that use session heavily can be impacted, its also a hygiene thing, nicer to keep all this secret info on the server instead of encrypted on the client.
Yikes, this tuning was done intentionally for security; it’s not a “badly configured” proxy. Tuning down the following nginx directives is commonly done as part of hardening nginx (to address availability, rate limiting, DOS, etc):
The settings we use in our nginx config work fine on all our existing sites. The problem here appears to be that Discourse stores unnecessary client data in the cookie, where imho the only thing stored in the cookie should be just a few unique identifiers that the server can use to access that data server-side.
Thanks Sam. By “moving to default use redis” are you suggesting that it’s currently possible to move the data stored in the session cookie to redis with a configuration change? Or would moving this data out of the session cookie to the server necessarily require a code change?
Nota: Também precisei sobrescrever o diretivo large_client_header_buffers da minha configuração endurecida do nginx para que o Discourse funcionasse.
Especificamente, uso large_client_header_buffers 2 1k nas configurações do nginx para todos os meus outros sites. No entanto, isso causa um erro 414 Request-URI Too Large em /admin/reports/bulk?XYZ – onde XYZ tem, na verdade, 1.019 caracteres de comprimento!
Isso foi corrigido definindo large_client_header_buffers 4 8k; no bloco server{} da configuração do nginx do Discourse, o que sobrescreve o diretivo global e restaura o valor padrão desse diretivo para o Discourse.
Para uma melhor interoperabilidade das instalações do Discourse em servidores web populares endurecidos, firewalls de rede e firewalls de aplicativos web, insto os desenvolvedores do Discourse a considerarem o uso de POST para cadeias de consulta tão longas.
Para alguém que não é um engenheiro de backend, qual é a correção para isso?
Estamos recebendo muitos relatos desse erro no último mês no fórum Webflow. Recomendar que um visitante limpe seus cookies/cache ou use o modo anônimo funcionou, mas não é o ideal.
Qualquer conselho sobre como corrigir isso para nossa instância do Discourse seria muito apreciado.
Você pode fornecer um link para um exemplo? Este problema no OP é sobre auto-hospedagem do Discourse, então não entendo como isso pode afetar uma instância hospedada como a que você vinculou.