Je n’ai pas d’installation locale de Discourse pour le moment, donc je ne suis pas sûr de pouvoir vous aider beaucoup.
La réponse 404 me fait me demander si Discourse Connect est bien activé sur votre site Discourse :
Il semble que vous testiez cela avec une application Angular locale et un site Discourse de production. Je m’attendrais à ce que cela fonctionne toujours, mais c’est peut-être la cause d’un problème. Vous devriez certainement pouvoir obtenir une réponse autre qu’une 404.
@simon merci pour votre réponse,
cela avait été confirmé plusieurs fois par moi-même,
et j’ai aussi un site de test en production qui était hébergé sur le domaine parent de ce site discourse. si vous pouvez jeter un œil à ce [lien supprimé]
pour tester le flux de production, j’ai mis à jour l’URL de Discourse Connect à « https://domainsite.com/login », n’hésitez pas à vous connecter avec le fournisseur Google et à faire un test. Dans le journal de la console d’inspection, vous verrez l’erreur et la réponse que j’ai imprimée, qui est 404.
puisque je fais juste la POC, si cela ne vous dérange pas, pourriez-vous me laisser votre e-mail afin que je puisse vous définir comme administrateur pour enquêter de près sur les configurations de mon site discourse. Encore une fois, j’apprécie vraiment votre temps et votre aide.
La seule partie dont je ne suis pas sûr, c’est le sig et le sso, est-ce que je le fais correctement à partir du code ?
À part cette partie. La clé API, je l’ai essayée pour tout le monde et uniquement pour le système, les résultats sont les mêmes. Si possible, veuillez me fournir un exemple fonctionnel pour Postman ou un code basé sur Angular.
J’ai manqué ceci lorsque j’ai regardé la capture d’écran de votre code pour la première fois :
mode : « no-cors »
Je ne connais pas les applications Angular, mais il semble que vous essayiez de faire une requête API authentifiée à Discourse depuis le client. Je ne suis pas sûr de l’endroit où cela se produit dans le code de Discourse, mais ma compréhension est que Discourse bloque les requêtes API d’administration qui sont effectuées à partir du client. C’est parce qu’il n’y a aucun moyen de faire la requête sans exposer la clé API sur le client. Parallèlement à cela, vous devriez changer votre clé API maintenant.
Merci d’avoir signalé cela,
on dirait que nous avançons d’un pas.
J’essaie également d’envoyer la requête depuis Postman.
Si vous pensez que le bloc côté client « mode: ‘no-cors’ » puisque Discourse a refusé d’accepter l’appel avec des clés API depuis le frontend, alors je pense que cela devrait aller de l’envoyer depuis Postman, est-ce correct ? mais le résultat est le même
J’ai même essayé de démarrer un serveur puis de déclencher le serveur pour envoyer la requête avec la clé API côté serveur, ce qui donne le même résultat, ce qui me donne l’impression qu’il me manque des configurations sur le site Discourse.
Il est judicieux de faire fonctionner cela depuis Postman, ou même simplement depuis la ligne de commande. D’après la capture d’écran que vous avez publiée, il semble que vous ayez le nom d’utilisateur de l’API (api-username) et la clé de l’API (api-key) dans le corps de la requête. Ces paramètres doivent se trouver dans l’en-tête de la requête. Le corps de la requête doit contenir les paires clé/valeur sig et sso. Si cela peut vous aider, voici comment le plugin WP Discourse le gère : wp-discourse/lib/plugin-utilities.php at main · discourse/wp-discourse · GitHub .
Génial ! C’est parti,
ça marche maintenant !
1000 mercis @simon
le problème était juste celui que vous avez mentionné :
sso et sig devraient être les deux seules paires de clés dans le corps
api-key et api-username devraient être dans les en-têtes
Comment ce comportement se manifestera-t-il si j’active ceci sur un site qui n’utilise pas actuellement external_id ? Parviendra-t-il à connecter les utilisateurs en se basant uniquement sur leur e-mail ?
Plus généralement, puisque email et external_id sont les 2 champs obligatoires dans la charge utile, pourriez-vous clarifier comment ils sont utilisés du côté de Discourse (lors de la réception de la charge utile du site d’authentification) pour déterminer quel compte utilisateur connecter ?
external_id n’a été associé à l’e-mail lors de la création de l’utilisateur, utilisera-t-il l’e-mail puis associera-t-il l’external_id à cet e-mail pour les futures connexions ?email et external_id (chacun étant associé à un compte Discourse différent), utilisera-t-il l’external_id ou l’email pour déterminer quel utilisateur connecter ? Ou générera-t-il une erreur ?Merci !
Je pense que votre question principale concerne le champ external_id. Vous devez définir un champ external_id dans la charge utile DiscourseConnect. La valeur du champ doit être une chaîne de caractères associée à l’utilisateur qui ne changera jamais. Je suppose que votre application a une table users. La clé primaire de l’entrée d’un utilisateur dans cette table serait une bonne valeur à utiliser pour le champ external_id.
Si un utilisateur a créé un compte sur Discourse avant que vous n’ayez ajouté l’authentification DiscourseConnect depuis votre site web, la première fois qu’il se connectera à Discourse via DiscourseConnect, Discourse tentera de trouver l’utilisateur en fonction de l’adresse e-mail qui se trouve dans la charge utile DiscourseConnect. Après avoir trouvé l’utilisateur, un enregistrement sera ajouté à la base de données Discourse qui contiendra l’external_id de la charge utile DiscourseConnect. La prochaine fois que l’utilisateur se connectera, il sera trouvé par l’external_id au lieu de l’adresse e-mail. (Notez que cela ne fonctionne pas si vous définissez le paramètre require_activation dans la charge utile DiscourseConnect sur true.)
Discourse dispose de bonnes solutions de repli pour la plupart des cas limites. Il existe des problèmes liés aux utilisateurs ayant plusieurs comptes et adresses e-mail qui peuvent déclencher des erreurs. Vous trouverez plus de détails sur la gestion de ces cas ici : Débogage et correction des problèmes courants de DiscourseConnect.
Très utile, merci ! On dirait que tout fonctionne comme je m’y attendais 
Nous utilisons DiscourseConnect avec WordPress comme fournisseur avec succès depuis plusieurs années et nous n’avons pas modifié les configurations de Discourse ou de WP. Aujourd’hui, j’ai remarqué ce qui me semble être un nouveau comportement.
Lorsque je me déconnecte, cela me redirigeait vers l’écran de connexion WordPress. Maintenant, cela me redirige vers l’écran de connexion Discourse. Si j’essaie de me connecter avec l’écran Discourse, j’obtiens une erreur inconnue, mais le fait est que je ne devrais pas y être du tout - je devrais être à la connexion WP.
Notez que j’ai activé les connexions locales (je ne sais pas pourquoi, puisque j’utilise WP). Si je désactive les connexions locales et que j’essaie de me connecter, il est indiqué qu’aucune méthode de connexion n’est disponible. Donc, je suppose qu’il n’aime pas ma connexion WP, mais encore une fois, je n’ai pas modifié les configurations des deux côtés. J’ai confirmé que Discourse Connect est activé, que l’URL de connexion est correcte et que le secret est le même des deux côtés.
À jour avec la version 3.5.0.beta5-dev. Le plugin WP Discourse est également à jour.
ça m’arrive aussi, je vais jouer avec pour voir si je trouve le problème.
Nous utilisons également DiscourseConnect et rencontrons le même problème.
Nous l’avons mis en place depuis quelques années maintenant et tout a fonctionné sans problème. Mise à jour aujourd’hui vers 3.5.0.beta8-dev [e91024a221]
Fondamentalement, le rappel du système sso vers l’URL de discourse ajoute https://discourse.domain.ext/login et nous avons le même écran que @markschmucker
Nous avons également remarqué qu’en cliquant sur le logo de l’en-tête, nous arrivons sur https://discourse.domain.ext/ et la connexion est réussie (il suffit de cliquer sur un bouton).
Il semble que dans la version précédente, le contrôleur de session se comportait différemment, comprenant probablement que l’appel était initié par le sso externe et le traitait de la bonne manière.
J’ai remarqué qu’au cours du dernier mois, @zogstrip a apporté des modifications qui pourraient être liées (pas à 100% sûr) au mauvais comportement.
Pour l’instant, nous avons appliqué une solution de contournement dans la méthode de rappel qui ajoutait /login à l’URL de discourse et tout semble fonctionner correctement.
Si je manque quelque chose comme de la documentation qui donnait des conseils sur un changement potentiellement perturbateur dans cette partie du code, faites-le moi savoir.
Merci à tous pour votre soutien.
@markschmucker, @jimkleiber, et @marco.palumbo, rencontrez-vous le même problème que celui décrit dans No login methods when using Discourse Connect only ?
Si oui, la solution consiste à vous assurer que le paramètre du site « authentification immédiate » est activé.
J’ai bien activé « authentification immédiate ».
Merci pour votre aide @zogstrip. Malheureusement, si j’active « authentification immédiate », je perds la possibilité d’avoir une page « bienvenue » pour les utilisateurs anonymes.
Il ne semble pas possible de supprimer un nom ou une avatar_url à l’aide de DiscourseConnect SSO. J’ai essayé de définir les champs sur une chaîne vide (confirmé par exemple que avatar_url= se retrouve dans le paramètre sso base64), mais je suppose que le code ignore les champs vides.
Les noms et les images sont facultatifs sur mon système, mais la façon dont cela fonctionne maintenant, une fois définis, ils ne peuvent jamais être désactivés, seulement remplacés. Y a-t-il une chance que je fasse quelque chose de mal ? (Sinon, peut-être que cela pourrait être corrigé ?)
[Edit] : J’avais déjà cherché une réponse, mais bien sûr, dès que j’ai posté ce qui précède, j’ai essayé de rechercher d’autres mots-clés et j’ai trouvé Allow name removal using SSO - #9 by mentalstring . J’ai voté pour cela, mais je ne me fais pas d’illusions. 
J’ai le même problème de redirection de connexion que @markschmucker, @jimkleiber et @marco.palumbo décrivent ci-dessus, que j’ai découvert il y a quelques semaines et qui fonctionnait correctement en mai. D’après ce que vous avez dit à ce sujet, je suis convaincu qu’il s’agit d’une régression dans Discourse introduite dans une mise à jour de mai, car cela nous a touchés tous en même temps, nous avions tous un code SSO fonctionnel, et nous ne partageons aucun code SSO commun.
J’ai posté un rapport de bug dans l’espoir que nous puissions le résoudre.
Le problème de redirection est résolu pour moi dans la version 3.6.0-beta1.
@markschmucker et @marco.palumbo
Il semble que ceci ait été corrigé il y a quelques semaines et que cela devrait de nouveau fonctionner correctement dans v3.6.0.beta1.