C’est une excellente information. Je n’ai pas encore vu spécifiquement de problème de CORS, mais je vais creuser davantage. Si je trouve quoi que ce soit, je le posterai ici.
Après avoir examiné les scripts, il semble que cela soit lié à Cloudflare. Utilisez-vous Cloudflare ? https://boards.neocron.org/cdn-cgi/apps/head/QNWX_8GN-3K7wUr6Qa73LdoD3JI.js. Nous ne l’utilisons pas, donc nous n’avons probablement pas rencontré ce problème spécifique.
Merci !
En creusant, nous avions activé Paramètres->Sécurité->politique de sécurité du contenu.
Une fois désactivée, les utilisateurs ont pu s’inscrire. Nous avons essayé d’ajouter les URL trouvées dans le rapport ci-dessus aux sources de script autorisées, mais cela n’a pas résolu le problème.
Chrome a apparemment renforcé sa CSP. → Manifest - Content Security Policy | Chrome Extensions | Chrome for Developers
Hmm, je crains que ce soit désactivé de notre côté ; cela devrait être une autre chose qui cause ce problème.
Nous avons également activé le drapeau CORS, mais nous ne savons pas si cela est lié.
Il s’agit d’un problème CSP, pas CORS.
Est-ce une configuration en sous-dossier ?
EDIT : en revenant sur ce sujet et en y regardant de plus près, je vois ce qui se passe.
Je peux confirmer que cela a été injecté par CF.
Nous recommandons FORTEMENT de ne pas désactiver CSP sur un site de production. À la place, désactivez Cloudflare si possible (nous avons eu NOMBREUX, NOMBREUX cas de support concernant l’impact négatif de CF sur le JS de Discourse) ou, à défaut, désactivez toutes les optimisations de Cloudflare.
Cela ouvre d’énormes failles de sécurité sur votre site. Nous RECOMMANDONS FORTEMENT de NE PAS faire cela. C’est un conseil très dangereux.
Salut @supermathie,
Nous n’utilisons pas Cloudflare et nous constatons actuellement ce problème avec 2 utilisateurs. La solution de contournement que nous leur proposons est d’utiliser la navigation privée ou un autre navigateur, mais il est possible que d’autres utilisateurs ne nous signalent pas ce problème.
Notre communauté est composée majoritairement de personnes non techniques, je ne pense donc pas qu’elles aient des configurations de navigateur étranges.
Pourrais-tu fournir plus d’informations sur ce qui déclenche ce problème ? Peut-être pourrais-je partir de là pour trouver une solution.
Merci !
Nous aimerions le savoir exactement nous-mêmes.
Il existe un champ de saisie caché sur l’écran « Création de compte » qui est vérifié pour son intégrité lors de la création du compte.
Si ce champ est modifié, la création du compte échoue.
Pourriez-vous demander à vos utilisateurs de désactiver leurs extensions une par une jusqu’à ce qu’ils identifient celle qui pose problème ?
Nous avons également ouvert un ticket auprès du projet Chrome pour enquêter sur ce comportement.
Permettez-moi de vous rappeler cette capture d’écran provenant de l’ordinateur d’un utilisateur non technique :
Vous ne pouvez rien présumer 
Oui, je veux dire que ce n’est plus 2000, la sécurité des navigateurs et la prévention des logiciels malveillants sont meilleures aujourd’hui (je le crois). Un autre utilisateur a signalé cela aujourd’hui, je vais essayer d’obtenir plus d’informations auprès d’eux et j’espère trouver quelque chose.
Merci !
Super. Nous tenons vraiment à régler ce point, alors faites-nous savoir.
J’ai un ami qui rencontre ce problème aussi — je tente de le recruter en tant que modérateur. Quand je m’inscris dans une fenêtre de navigation privée, tout fonctionne correctement, mais lui ne peut même pas le faire, et ce, dans une fenêtre de navigation privée. Je suis donc convaincu que le problème ne vient pas de mon installation (j’utilise des plugins avec mon Discourse, mais uniquement des officiels), mais plutôt de son navigateur quelque part.
Je travaille avec lui pour identifier précisément le problème, mais si ce n’est pas un problème de plugin, je me demande s’il y a un souci lié à nos versions de Chrome — peut-être qu’il se passe quelque chose sous le capot du navigateur dont je n’ai pas connaissance, mais je ne peux pas encore l’affirmer avec certitude. J’essaie actuellement d’obtenir son numéro de version pour comparer, mais comme il est en Californie, s’il est raisonnable, il doit être endormi 
D’accord, ce n’est pas logique, mais il est réveillé et donne des informations. Il a effectué une mise à jour de la version 75.0.3770.142 vers la 76.0.3808.87 (64 bits), ce qui n’a pas résolu le problème seul dans la fenêtre principale, mais après avoir vidé le cache et les cookies, il a pu s’inscrire dans une fenêtre de navigation privée. Il utilise une configuration Chrome entièrement standard, à l’exception d’un bloqueur de publicités.
EDIT : Je ne saurais pas dire si vider le cache ou les cookies aurait fonctionné sur la version 75.0.3770.142 sans pouvoir reproduire le problème (je ne peux pas), mais je trouve intéressant que cela ait au moins semblé aider mon ami.
Bonjour, j’ai configuré une nouvelle instance aujourd’hui sur community.boid.com et j’ai rencontré ce message d’erreur après avoir essayé de créer un deuxième compte (à la fois dans ma fenêtre Chrome normale et en navigation privée). J’ai pu résoudre le problème en supprimant manuellement les mots de passe automatiques de mon compte Google et en n’utilisant aucune option de remplissage automatique dans le formulaire d’inscription. J’ai remarqué que Chrome proposait de nombreuses options d’authentification différentes pour le remplissage automatique provenant d’autres sites sans rapport. Je n’ai pas observé ce comportement sur d’autres sites, je voulais donc simplement partager mon expérience.
À ma connaissance, cela semble bien être lié au remplissage automatique de Google Chrome.
J’ai une méthode pour reproduire ce problème, mais elle est tortueuse. Vous aurez besoin de deux fenêtres de navigateur.
Chargez votre site en mode navigation privée et ouvrez la fenêtre de dialogue « Créer un nouvel utilisateur ».
Dans une deuxième fenêtre de navigateur, connectez-vous en tant qu’administrateur. Accédez aux paramètres du site. Activez l’option « Sur invitation uniquement », ce qui désactive l’inscription publique.
Dans le navigateur en mode navigation privée, tentez de finaliser l’inscription en tant que nouvel utilisateur via la fenêtre de dialogue « Créer un nouvel utilisateur » que vous avez ouverte précédemment.
Vous ne pourrez pas le faire, car la création de nouveaux utilisateurs n’est plus autorisée, vous verrez donc… notre vieil ami…
Au moins, nous avons cette méthode de reproduction, même si elle est… folle. 
Je n’ai jamais, au grand jamais, réussi à reproduire ce problème d’une autre manière, et personne dans ce sujet n’a jamais pu fournir une série d’étapes de reproduction sur une instance par défaut de Chrome sans aucun plugin. Si vous le pouvez, n’hésitez pas à nous fournir ces étapes de reproduction…
J’ai reproduit cette erreur sur try.discourse.org :
Très bien, c’est un cas reproductible sur lequel nous pouvons travailler, merci pour cela.
Cependant, notez qu’il nécessite toujours une action manuelle de l’utilisateur — clic droit dans le champ de mot de passe lors de la création d’un nouveau compte / de l’inscription et appuyez sur « suggérer ». Je dois f5 actualiser la page avant d’ouvrir la boîte de dialogue d’inscription pour que cela apparaisse de manière fiable, mais ensuite cela fonctionne.
Maintenant que nous avons une sorte de cas reproductible @sam, pouvons-nous assigner la tâche ?
Nous avons deux mécanismes en place pour empêcher les robots de créer des comptes de manière aveugle.
Nous simulons un champ « confirmation du mot de passe » qui est en réalité un « piège » : nous attendons une valeur très spécifique. Il s’agit d’une boîte de saisie (INPUT) qui n’est pas affichée à l’écran, mais qui se trouve dans une div masquée.
Nous utilisons une chaîne de défi que nous attendons que le JavaScript traite et renvoie.
Si l’une ou l’autre de ces conditions (1) ou (2) n’est pas respectée, nous considérons la requête comme suspecte et ne procédons pas à l’enregistrement du compte.
Ce que fait le gestionnaire de mots de passe de Chrome, c’est « remplir » le champ new-account-confirm avec le mot de passe :
{{input type="password" value=accountPasswordConfirm id="new-account-confirmation" autocomplete="new-password"}}
Cet INPUT est masqué et n’est pas rendu à l’écran.
Nous avons deux alternatives ici.
Supprimer cette protection et accepter comme une évidence que les gestionnaires de mots de passe font des erreurs ici. Ils ne vérifient pas si un champ « confirmation du mot de passe » est réellement visible avant de le remplir.
Demander à l’équipe de Chrome d’arrêter de faire cela : remplir des champs INPUT qui ne sont pas visibles n’est pas correct. (Je l’ai déjà fait)
Je ne sais pas… Je suppose que nous pouvons opter pour l’option (1), c’est un changement simple. Je pourrais supprimer la protection et faire en sorte que le client JavaScript calcule un hachage à la manière du Bitcoin pour prouver qu’il effectue un travail. Par exemple, je donne au client une chaîne et lui demande d’ajouter des chiffres jusqu’à ce que le MD5 se termine par 00. Cela serait pénalisant pour les robots et très peu coûteux à vérifier côté serveur.
Forcer les robots à calculer aveuglément des MD5, je suppose, est une façon de les obliger à payer les factures et de financer ma retraite aux Bahamas.
Est-il possible de désactiver complètement un tel mécanisme et de réactiver l’ancien Google CAPTCHA ? Je pense que cela permettrait de maintenir la sécurité tout en permettant à plus d’utilisateurs de s’inscrire.
Ou alors, nous pouvons attendre votre correctif urgent. Quelle option vous semble la meilleure ? Nous lancerons un grand flux de nos partenaires sur notre forum au début de la semaine prochaine.
Je viens de créer un nouveau compte, sans aucun logiciel anti-spam / anti-espion / autre sur le navigateur, et j’ai rencontré le même problème. Je l’ai résolu en utilisant la méthode « se connecter avec Google », et cela a fonctionné par la suite.
