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

Warum hat Discourse so große Cookies? Gibt es dafür einen Grund? Gibt es eine Möglichkeit, ihre Größe zu verringern?

Ich habe mich im Discourse-Admin-Dashboard umgesehen und plötzlich eine 400 Bad Request-Fehlermeldung von /sidekiq/retries erhalten.

400 Bad Request
Request Header Or Cookie Too Large

Ich habe die Anfrage geprüft und tatsächlich hat mein Browser einen riesigen Cookie-Header an meinen Discourse-Server gesendet. Warum?

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

Der oben genannte Discourse-Cookie-String ist 1.962 Zeichen lang!

Zum Vergleich: Der Cookie-Header, der an meine Mediawiki-Seite gesendet wird, ist nur 122 Zeichen lang, einschließlich meines Benutzernamens, der Benutzer-ID und der Sitzungs-ID.

Die Mediawiki-Sitzungs-ID ist 32 Zeichen lang, aber Discourse scheint zwei Sitzungs-IDs zu haben: rack.session ist 813 Zeichen lang und _forum_session ist 1.075 Zeichen lang. Bitte helfen Sie mir zu verstehen, warum eine einfache UID so lang sein muss. Kann ich Discourse so konfigurieren, dass es eine kürzere Sitzungs-UID verwendet? Ist eine solche Anfrage sinnvoll?

Was ist in diesem String gespeichert? Ist es möglich, ihn kleiner zu machen?

Insbesondere, wofür wird die Komponente rack.session der Discourse-Software verwendet? Und wofür wird _forum_session verwendet?

Natürlich kann ich einfach die nginx-Konfigurationsgrenzen erhöhen, aber ich möchte sie so niedrig wie möglich halten, es sei denn, es besteht ein zwingender Bedarf, sie zu erhöhen.

Ich unterstütze die Überprüfung unserer Sitzungs-Cookies und vielleicht einfach den Wechsel zur standardmäßigen Nutzung unserer Redis-basierten Sitzung, die automatisch abläuft – was ohnehin besser ist. @david, hast du dazu Gedanken?

Das sollte für jemanden, der unsere offizielle Installation verwendet, kein Problem sein, sondern nur für Personen mit schlecht konfigurierten Proxys, oder?

Außerdem sorgt die HTTP/2-Headerkomprimierung dafür, dass diese Header nur einmal während des gesamten Benutzerbesuchs hochgeladen werden.

Kommt darauf an. Plugins, die stark auf Sitzungen angewiesen sind, können betroffen sein. Außerdem ist es eine Frage der Sauberkeit: Es ist besser, alle diese vertraulichen Informationen auf dem Server zu behalten, statt sie auf dem Client verschlüsselt abzulegen.

Oh je, diese Anpassungen wurden absichtlich aus Sicherheitsgründen vorgenommen; es handelt sich nicht um einen „schlecht konfigurierten

Nein, dafür ist eine Code-Änderung erforderlich.

Warum sind 10 kB an Headern ein Problem? Sie werden komprimiert. Wenn 10 kB an Headern ein Problem darstellen, warum ist dann eine 10 kB große HTML-Nutzlast erlaubt?

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.

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

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.

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.