Discourse-Sitzungs-Cookies (400 Request Header or Cookie Too Large)

Unterstützung Installation
1

Why does Discourse have such large cookies? Is there a reason for it? Is there a way to decrease their size?

I was poking around in the Discourse admin dashboard, and I suddenly got a 400 Bad Request error back from /sidekiq/retries

400 Bad Request
Request Header Or Cookie Too Large

I checked the request and, sure enough, my browser sent a huge Cookie header to my Discourse server. Why?

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

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.

2

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?

3

This shouldn’t be a problem for someone using our official install, just for people using badly configured proxies right?

Also HTTP/2 header compression makes for this headers to be uploaded just once in the entire user visit.

4

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.

6

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):

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

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?

7

Nope, requires a code change

Why is 10k worth of headers a problem? They are compressed, if 10k of headers is a problem why is 10k html payload allowed?

9

Hinweis: Ich musste auch die Direktive large_client_header_buffers in meiner abgesicherten nginx-Konfiguration überschreiben, damit Discourse funktioniert.

Insbesondere verwende ich für die nginx-Konfigurationen aller meiner anderen Websites large_client_header_buffers 2 1k. Dies führt jedoch zu einem Fehler 414 Request-URI Too Large von /admin/reports/bulk?XYZ – wobei XYZ tatsächlich 1.019 Zeichen lang ist!

Dies wurde behoben, indem ich im server{}-Block meiner Discourse-nginx-Konfiguration large_client_header_buffers 4 8k; festgelegt habe. Dadurch wird die globale Direktive überschrieben und der Standardwert für Discourse wiederhergestellt.

Für eine bessere Interoperabilität von Discourse-Installationen über gängige abgesicherte Webserver, Netzwerk-Firewalls und Web Application Firewalls hinweg fordere ich die Discourse-Entwickler nachdrücklich auf, für derart lange Query Strings POST-Methoden zu verwenden.

10

Das ist ein sehr, sehr spezifischer Anwendungsfall – spezifisch für Administratoren.

11

Für jemanden, der kein Backend-Entwickler ist, wie behebt man das?

Wir erhalten seit letztem Monat viele Berichte über diesen Fehler im Webflow-Forum. Die Empfehlung, dass ein Besucher seine Cookies/Cache löscht oder den Inkognito-Modus verwendet, hat funktioniert, ist aber nicht ideal.

Jeder Rat zur Behebung dieses Problems für unsere Instanz von Discourse wäre sehr willkommen.

12

Können Sie ein Beispiel verlinken? Bei dem Problem in OP geht es um das Self-Hosting von Discourse, daher verstehe ich nicht, wie es eine gehostete Instanz wie die von Ihnen verlinkte beeinträchtigen kann.