Cela continue de se produire de manière aléatoire pour tous les utilisateurs. Cela ne m’est pas arrivé, mais j’ai été déconnecté une fois lorsque cela est arrivé à quelqu’un d’autre. Je n’ai aucune idée par où commencer à chercher.
J’ai un fil de discussion sur mon forum que j’ai rendu public pour fournir plus d’informations. Cette fois, 2 utilisateurs se sont connectés en tant que le même utilisateur, l’un était un administrateur, l’autre non. L’utilisateur qu’ils sont devenus n’est même pas actif.
@Falco Tout éclaircissement sur où chercher est apprécié.
@Falco c’est un problème récurrent depuis plusieurs années. D’après ce que je sais, il s’agit d’un problème côté client avec la session utilisateur et l’ID utilisateur spécifiquement. Ce problème n’est contourné que et non résolu si, au lieu de la connexion locale, c’est-à-dire l’authentification locale, l’authentification tierce est utilisée.
Pouvez-vous confirmer que cela est dû à votre authentification locale médiocre ?
Avec tout le respect que je vous dois, il existe des milliers d’installations de Discourse sur Internet. Rien que dans notre hébergement, nous en gérons des milliers, et il y en a beaucoup en auto-hébergement aussi, et votre instance est la seule à signaler ce problème. Cela signifie que votre problème est très probablement auto-infligé.
Puisque vous utilisez un proxy inverse personnalisé devant Discourse, je commencerais par le supprimer et passer à notre configuration d’installation standard approuvée avant de signaler le bug en amont ici.
Je ne suis pas sûr de ce qui rend mon installation personnalisée par rapport à ce qui est intégré dans Discourse, car chacun utilise nginx. Il ne m’est pas possible de le supprimer, car Discourse n’est pas la seule chose que j’héberge. Je suis sûr que c’est mon problème, mais s’il est possible que cela arrive pour moi, il est également possible que cela arrive pour quelqu’un d’autre. Je n’ai pas d’autres problèmes avec les logiciels que j’héberge. Je ne demande pas que vous me teniez la main ici, mais je ne peux rien trouver d’autre qui cloche.
S’il n’y a pas d’autre insight que vous pourriez donner quant à l’endroit où regarder, peut-être connaissez-vous quelqu’un qui peut. J’ai essayé de vérifier les logs sur les deux conteneurs ainsi que sur leurs hôtes respectifs. Je ne sais pas où chercher d’autre pour comprendre ce qui a mal tourné.
Je peux comprendre le manque de soutien. Nous ne sommes pas des clients payants et certains d’entre nous ne sont même pas très polis. Je ne vous en veux pas de me pointer du doigt car je suis d’accord, c’est quelque chose que je fais différemment qui cause cette migraine. Si vous croyez sincèrement que le proxy inverse est la cause de ce problème, cela ne poserait-il pas un gros problème de sécurité ?
Je ne sais pas ce que je ne sais pas sur le fonctionnement interne de discourse, mais pour moi, cela semble quelque chose qui devrait intéresser les développeurs.
Oui, c’est définitivement un problème de sécurité. Mais si cela ne se produit que sur cette instance spécifique, c’est un problème de sécurité sur votre site, et non sur Discourse, n’est-ce pas ?
Je serais heureux d’aider. Seriez-vous ouvert à déplacer le site sur un serveur séparé pendant quelques semaines en utilisant notre installation standard pour exclure tout problème de proxy inverse ?
Si mon proxy inverse est capable de corrompre un jeton ou autre de la bonne manière, de sorte que Discourse pense qu’un utilisateur est devenu quelqu’un d’autre… est-ce que cela importe vraiment si le problème réside dans le proxy inverse ? Cela n’indiquerait-il pas quelque chose d’exploitable ailleurs ?
Encore une fois, ne sachant pas ce que je ne sais pas sur le fonctionnement de l’authentification.
Nous avons abandonné l’hébergement tiers en raison de l’augmentation des coûts, mais il existe peut-être un autre moyen de résoudre ce problème. J’examinerai le proxy inverse. Actuellement, j’utilise ce conteneur pour une administration facile, mais je pourrais essayer quelque chose de différent.
Je sais que vous dites que cela ne m’arrive qu’à moi, et je n’ai aucune preuve du contraire, mais cela signifie-t-il vraiment que ce n’est possible pour personne d’autre ?
Je vais examiner la configuration nginx fournie par Discourse pour voir si je peux comprendre où je fais quelque chose de mal. J’apprécie votre point de vue.
Je ne prétends pas que je comprendrais quoi que ce soit ici et maintenant, mais quand j’ai commencé à utiliser Discourse, j’avais Varnish devant Discourse, et j’ai rencontré beaucoup de choses étranges, comme du contenu erroné.
Discourse fait son propre cache et pratiquement tout type de cache par un proxy inverse est une très mauvaise idée. Mais bien sûr, mes compétences très limitées sont très différentes de ce que les Big Guys™ peuvent faire.
Il voulait que je supprime complètement le proxy inverse. Il s’agit simplement de supprimer certaines choses de la configuration du proxy. Je ne savais pas que Discourse effectuait une mise en cache interne qui entrerait en conflit avec la mise en cache externe, c’est donc une suggestion utile.
[quote=“Jakke Lehtonen, post:33, topic:328698, username:Jagster”]
Donc, vous allez essentiellement faire ce que Falco a déjà suggéré plusieurs fois maintenant.
[/quote]Le lien qu’il continue de spammer est ce que nous faisons déjà :
ces étapes fonctionneront sur n’importe quel fournisseur de cloud compatible avec Docker ou sur un serveur local.
Il utilise le conteneur standard. La documentation mentionne l’utilisation d’une machine « compatible avec Docker », ce qu’il utilise. La documentation mentionne même l’utilisation d’un serveur local, ce qu’il utilise.
Il n’y a aucune mention d’utilisation d’un proxy spécial approuvé ou de désactivation de la mise en cache.
Il existe également une documentation pour la configuration de l’authentification unique (SSO), qui semble avoir causé des problèmes similaires à ceux que nous rencontrons actuellement :
Toujours aucune mention de configuration de la mise en cache ou de solutions de proxy inverse « personnalisées ».
Au minimum, je suggérerais de mettre à jour la documentation pour mettre en évidence ces problèmes potentiels, car ils sont si évidents pour les experts de Discourse.
Je serais très inquiet de cette configuration de mise en cache. Je ne comprends pas entièrement la documentation nginx pour proxy_ignore_headers, mais par défaut, nginx ne mettra pas en cache les réponses qui incluent un en-tête Set-Cookie. Il semble que cette configuration modifie ce comportement de sorte que les réponses incluant un en-tête Set-Cookiepourraient être mises en cache. Si elles sont mises en cache avec l’en-tête Set-Cookie et ensuite servies à un utilisateur différent, cela pourrait bien amener quelqu’un à changer de compte utilisateur.
En théorie, cette configuration ne devrait s’appliquer qu’aux fichiers multimédias, mais faire correspondre la fin d’une URL (y compris les paramètres de requête ?) semble être un moyen assez peu sûr de le faire.
J’ai arrêté de l’utiliser. Comme d’autres l’ont souligné, cela semble être une très mauvaise idée en général. J’apprécie l’explication. Je n’ai pas immédiatement vu quelque chose de mal dans ce qu’il faisait, mais je ne suis certainement pas un expert en la matière.
Je soupçonne que cela soit correct d’après l’explication donnée par @simonk.
Je remercie l’aide de tout le monde.
Je vais essayer de mettre à jour cela dans un moment pour donner un oui ou un non. Cela devrait être un avertissement utile pour les autres si c’est le cas.
