Cookies de sessão do Discourse (400 Cabeçalho de Solicitação ou Cookie Muito Grande)

Suporte Instalação
1

Por que o Discourse tem cookies tão grandes? Há um motivo para isso? Existe uma maneira de reduzir o tamanho deles?

Estava explorando o painel administrativo do Discourse e, de repente, recebi um erro 400 Bad Request de /sidekiq/retries.

400 Bad Request
Cabeçalho de solicitação ou cookie muito grande

Verifiquei a solicitação e, de fato, meu navegador enviou um cabeçalho de Cookie enorme para o servidor Discourse. Por quê?

Cookie: _t=403b8203003bdaf522679e0b6c17605f; rack.session=BAh7C0kiD3Nlc3Npb25faWQGOgZFVG86HVJhY2s6OlNlc3Npb246OlNlc3Np%0Ab25JZAY6D0BwdWJsaWNfaWRJIkU4NjY1Y2Y3MjU4OGYzZjk3MDUyMDdhNzhh%0ANzc4OGZlZTRhNzFkY2JjMzA4NDAyNjY3MWMwNmFhYzc2Zjg0NWIyBjsARkki%0AEF9jc3JmX3Rva2VuBjsARkkiMW9KNk83S1B5ZUVaR0I2WnBxckxISzNxbEla%0AdGRyVXNCUnc3d2JiaVorVmM9BjsARkkiFnNlY3VyZV9zZXNzaW9uX2lkBjsA%0AVEkiJWM3YWJjYTk3OTRlNTExNTllZWUyMTBkYmVkNDgzNDc4BjsARkkiCmZs%0AYXNoBjsAVHsHSSIMZGlzY2FyZAY7AFRbAEkiDGZsYXNoZXMGOwBUewZJIgxy%0AZWZlcmVyBjsAVCJPaHR0cHM6Ly9kaXNjb3Vyc2Uub3BlbnNvdXJjZWVjb2xv%0AZ3kub3JnL3UvbWFsdGZpZWxkMC9tZXNzYWdlcy9ncm91cC9hZG1pbnNJIglj%0Ac3JmBjsARkkiMVRuUHJ6TTMzUHZqcG9oditwdTRyem9HeDUxQnAwL0psci9z%0AYkFZWkpxdkU9BjsARkkiDXRyYWNraW5nBjsARnsGSSIUSFRUUF9VU0VSX0FH%0ARU5UBjsAVEkiLTk3MDJkMjYxMmJlZmM5N2U4YTIzMDVkNjU0Y2IwOThmMmQ4%0AYTI1NTUGOwBG%0A--e602081dddcd88bdb269034e7acb8c582665be0e; _forum_session=V2dWY0FGVGhsMDVtcmdmNVdicXpJVkxnVC9vUWpkeVdpSHRIYWZaVVhVZDUxcFlRdTh4bHFTQVRRcUpGR3pMRGZ1M3NGeENzUloreGdEWEtQS2Z2WDJKNFZUeXRjNXlTTTRHVzJsQzBORzVuSW9NNHg3UHhwNzdUNFlCNGVvcytkSjA1b0d3NlM3czNlTlFxMEloQmNOYzMxTm5mYW4zaWlMSkpxWXZiZDlBRFJnR3dxTkphM0ZtZmk4bGswcUdzYm94b3pkUk0zTG5sMjhqNkxYMnZqMjJPYkhzMGFLM2JWZzBCRXpFa2wyZm1HbUl3REVzd3c5MmhRMG5YMkFJV0t6Z2ZPRlI2bVpOQWJlZWJQd2pyclEvdmVmWUlsYkxyU0EzcDFaZkRpOU14SVptMk01TjZtZlNXa2VUQnFaaGZpNDlaQVBnY0RCS2ZlbVBiQWt3S2lSeHcvY0g2WUlXOTRLejh2dVhhcDFoRXVobUdRMnJvcjhtRTkxZjZCYXM1eDd2NU1rZ3duRy83VVhVSG5Ua3BIOTJoQ1orY2dlMjh2M0Fuc0lwb3p3ckVtaXhxaDkxT2E1YnEvbnBWTVlCaXd4Q2h6eTd5Ty84WUYzeUVFbE9KSXhadXZ4aUw1TmVoSEE0cW9YSHA3VTJoK3NtdktrL09qcDVxMnR5bFhhUmU1dDMzT0ZBUGxBRXBZVHB5WlNtODM2YzBsOVRkc3RpMmFFSW5COEhyRjFTY2ZCZk5VbUpYN2JzYlh6SGNGWEs2dWhQUkJnMmd4K3ZJQUFkQThwa2tOMnI3Vi9qMFo5RE5XWWxxRXFTTTNmRnJKU294aStKZFJ4NHRDTGh4WXR1Z3F5QWU3ZkMxTXBpMzcvYTd5QkRwajNjcDF6SWdFSkdqNDJlMk0vYW1mODNEdDhZSk9jbzRPRHNhZUYzNjVOWkErbVJSNG82VnhRL0FFRUtWbE1uQWFPa0JqQUFmZ21iL0YvSFIrM1dlSDNvPS0tK1pMRzNmRjA4L3c4VTkrVEllYmNQZz09--325ca2e886afaefffeb6174c99776f91fefd4292

A string de cookie do Discourse acima tem 1.962 caracteres de comprimento!

Para comparação, o cabeçalho de cookie enviado para meu site Mediawiki tem 122 caracteres, incluindo meu nome de usuário, ID de usuário e ID de sessão.

O ID de sessão do Mediawiki tem 32 caracteres, mas o Discourse parece ter dois IDs de sessão: rack.session tem 813 caracteres e _forum_session tem 1.075 caracteres. Por favor, ajude-me a entender por que um simples uid precisa ser tão longo. Posso configurar o Discourse para usar um uid de sessão mais curto? Faz sentido fazer tal solicitação?

O que é armazenado nessa string? É possível torná-la menor?

Especificamente, para qual componente do software Discourse o rack.session é usado? E para que serve o _forum_session?

Claro, posso apenas aumentar os limites de configuração do nginx, mas gostaria de mantê-los razoavelmente baixos, a menos que haja uma forte necessidade de aumentá-los.

2

Eu apoio auditar nossos cookies de sessão e talvez migrar para o uso padrão de nossa sessão com suporte ao Redis, que expira automaticamente e é melhor de qualquer forma. @david, o que você acha disso?

3

Isso não deveria ser um problema para quem usa nossa instalação oficial, apenas para pessoas com proxies mal configurados, certo?

Além disso, a compressão de cabeçalhos HTTP/2 faz com que esses cabeçalhos sejam enviados apenas uma vez durante toda a visita do usuário.

4

Depende. Plugins que usam muito a sessão podem ser afetados. Também é uma questão de higiene: é melhor manter todas essas informações secretas no servidor em vez de criptografadas no cliente.

6

Uau, esse ajuste foi feito intencionalmente por segurança; não se trata de um proxy “mal configurado”. A redução dos seguintes diretivos do nginx é comumente realizada como parte do endurecimento (hardening) do nginx (para tratar disponibilidade, limitação de taxa, ataques de negação de serviço, etc):

limit_conn_zone
limit_conn
limit_req_zone
client_body_timeout
client_header_timeout
ssl_*
add_header # SAMEORIGIN/XSS-Protection/CORS/CSP
client_body_buffer_size
client_header_buffer_size
large_client_header_buffers
client_max_body_size

As configurações que usamos no nosso arquivo de configuração do nginx funcionam bem em todos os nossos sites existentes. O problema aqui parece ser que o Discourse armazena dados desnecessários do cliente no cookie, quando, na minha opinião, a única coisa que deveria ser armazenada no cookie seriam alguns identificadores únicos que o servidor pode usar para acessar esses dados no lado do servidor.

Obrigado, Sam. Ao dizer “migrar para o uso padrão do Redis”, você está sugerindo que atualmente é possível mover os dados armazenados no cookie de sessão para o Redis com uma alteração de configuração? Ou mover esses dados do cookie de sessão para o servidor necessitaria de uma alteração no código?

7

Não, é necessária uma alteração no código.

Por que 10k de cabeçalhos seria um problema? Eles são comprimidos; se 10k de cabeçalhos é um problema, por que 10k de payload HTML são permitidos?

9

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.

10

Esse é um caso de uso muito, muito específico… voltado para administradores.

11

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.

12

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.