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.
Je soutiens l’audit de nos cookies de session et peut-être simplement passer par défaut à notre session basée sur Redis qui expire automatiquement, ce qui est de toute façon mieux. @david, qu’en penses-tu ?
Cela ne devrait pas poser de problème pour quelqu’un qui utilise notre installation officielle, seulement pour les personnes utilisant des proxies mal configurés, n’est-ce pas ?
De plus, la compression d’en-têtes HTTP/2 permet de ne transmettre ces en-têtes qu’une seule fois lors de toute la visite de l’utilisateur.
Cela dépend. Les plugins qui utilisent beaucoup les sessions peuvent être affectés. C’est aussi une question d’hygiène : il est préférable de garder toutes ces informations confidentielles sur le serveur plutôt que chiffrées côté client.
Ouh là, ce réglage a été effectué intentionnellement pour des raisons de sécurité ; il ne s’agit pas d’un proxy « mal configuré ». Réduire les directives nginx suivantes est une pratique courante dans le cadre du durcissement de nginx (pour gérer la disponibilité, la limitation du débit, les attaques DDoS, etc.) :
Les paramètres que nous utilisons dans notre configuration nginx fonctionnent parfaitement sur tous nos sites existants. Le problème ici semble être que Discourse stocke des données client inutiles dans le cookie, alors que, selon moi, le cookie ne devrait contenir que quelques identifiants uniques permettant au serveur d’accéder à ces données côté serveur.
Merci Sam. En parlant de « passer par défaut à l’utilisation de Redis », suggères-tu qu’il est actuellement possible de déplacer les données stockées dans le cookie de session vers Redis via un changement de configuration ? Ou bien le déplacement de ces données hors du cookie de session vers le serveur nécessiterait-il nécessairement une modification du code ?
Pourquoi 10 ko d’en-têtes poseraient-ils problème ? Ils sont compressés. Si 10 ko d’en-têtes posent problème, pourquoi un payload HTML de 10 ko est-il autorisé ?
Remarque : J’ai également dû remplacer la directive large_client_header_buffers de ma configuration nginx renforcée pour que Discourse fonctionne.
Plus précisément, j’utilise large_client_header_buffers 2 1k pour les configurations nginx de tous mes autres sites. Cela provoque cependant une erreur 414 Request-URI Too Large depuis /admin/reports/bulk?XYZ — où XYZ fait en réalité 1 019 caractères de long !
Cela a été résolu en définissant large_client_header_buffers 4 8k; dans le bloc server{} de la configuration nginx de Discourse, ce qui remplace la directive globale et rétablit la valeur par défaut de la directive pour Discourse.
Pour une meilleure interopérabilité des installations de Discourse via des serveurs web populaires renforcés, des pare-feu réseau et des pare-feu d’applications web, j’invite les développeurs de Discourse à envisager l’utilisation de POST pour de telles chaînes de requête longues.
Pour quelqu’un qui n’est pas un ingénieur backend, quelle est la solution ?
Nous recevons de nombreux rapports de cette erreur au cours du dernier mois sur le forum Webflow. Recommander à un visiteur de vider ses cookies/son cache ou d’utiliser le mode incognito a fonctionné, mais ce n’est pas idéal.
Tout conseil pour résoudre ce problème pour notre instance de Discourse serait très apprécié.
Pouvez-vous fournir un lien vers un exemple ? Ce problème dans le message initial concerne l’auto-hébergement de Discourse, donc je ne comprends pas comment il pourrait affecter une instance hébergée comme celle que vous avez liée.