C’est exactement ce que j’avais en tête aussi.
J’inclurai le lien vers le sujet Category Group Review/Moderation car j’ai d’abord eu du mal à le trouver en cherchant.
J’ai toujours du mal à trouver la Documentation dans la catégorie Announcements
2 « J'aime »
Honnêtement, c’est probablement une bonne idée quoi qu’il arrive. Les administrateurs ont TOUS les droits (télécharger des sauvegardes, voir/modifier les secrets de configuration, voir les données personnelles des utilisateurs, accéder aux messages personnels, …) et il est préférable de garder ce cercle restreint.
Il y a beaucoup de place pour des « privilèges élevés » sans être des administrateurs complets.
2 « J'aime »
Merci à vous deux pour cela, je n’étais pas au courant que c’était une chose distincte !
Merci pour cette clarification, je n’étais pas au courant que c’était le cas. Vous avez raison, nous limiterions certainement cela maintenant que je le sais.
J’ai examiné les limites/exigences de ceci et je l’ai transmis à mon équipe. Il semble malheureusement que nous devrions toujours auto-héberger. L’hébergement FOSS que vous proposez est très généreux, nous ne rentrons tout simplement pas dans les exigences.
Le plus gros problème étant les limites de vues de page. 50 000 vues de page par mois est probablement plus que suffisant pour la plupart des projets FOSS, mais nous générons beaucoup plus de trafic que cela. Notre site Web principal a reçu 1,87 million de requêtes au total de la part de 56,47 000 visiteurs uniques au cours des 7 derniers jours seulement. Je crains que nous n’atteignions facilement la limite de vues de page à ce rythme.
Merci de me l’avoir signalé cependant !
4 « J'aime »
Il vaudrait probablement la peine de trouver un moyen de gérer cela. Si vous savez quels utilisateurs sur votre serveur sont du personnel Discourse (administrateurs ou modérateurs), vous pourriez définir le champ e-mail SSO pour ces utilisateurs avec leur adresse e-mail réelle. Toutes les adresses e-mail en double qu’ils ont recevraient l’adresse e-mail fictive.
Il y a quelques cas où il est utile que le personnel puisse recevoir des e-mails de Discourse. Le premier que vous rencontrerez probablement est que Discourse fournit une route /u/admin-login pour les utilisateurs du personnel. Cette route affiche un formulaire qui accepte une adresse e-mail du personnel. Discourse enverra un lien de connexion à usage unique au membre du personnel. C’est pratique pour configurer le SSO - si vous vous bloquez accidentellement hors du site lors de sa configuration, cela vous permettra de revenir. C’est également utile s’il y a un problème avec votre serveur d’authentification.
1 « J'aime »
Je suis d’accord, et c’est quelque chose auquel j’ai réfléchi (pour des raisons extérieures à Discourse). Le gros problème vient du fait que les membres réguliers peuvent devenir, et sont devenus, du personnel. Donc, même si nous exigions des e-mails uniques pour les utilisateurs du personnel, nous ne pourrions pas garantir que les utilisateurs les aient, ce qui causerait des problèmes lorsqu’un utilisateur dont le compte a un e-mail en double devient membre du personnel.
Cela dit, maintenant qu’il est clair que DiscourseConnect utilise d’abord l’ID unique pour la recherche d’utilisateurs et que la partie « Discourse utilise les e-mails pour associer les utilisateurs externes aux utilisateurs Discourse » du message DiscourseConnect ne fait référence qu’à la liaison de nouveaux utilisateurs SSO à des comptes Discourse existants, et que mon incompréhension du fonctionnement de l’invite de connexion a été clarifiée, y a-t-il quelque chose qui nous empêche réellement d’envoyer simplement des adresses e-mail en double telles quelles ? Ou cette unicité est-elle strictement appliquée ?
Oui. J’ai omis une étape dans ma description du flux de connexion. Discourse essaiera d’abord de trouver l’utilisateur en fonction de external_id, puis essaiera de trouver l’utilisateur en fonction de son email. Si aucun des deux n’est trouvé, Discourse tentera de créer l’utilisateur. C’est ainsi que vos utilisateurs seront initialement enregistrés sur Discourse. Discourse n’autorise pas les adresses e-mail en double, donc si une tentative est faite pour créer un utilisateur avec une adresse e-mail déjà utilisée, Discourse générera une erreur.
Vous devrez vous assurer que les e-mails envoyés dans la charge utile sont uniques par utilisateur.
Compris, merci pour cette clarification 
est-il possible de mettre à jour manuellement l’e-mail d’un utilisateur plus tard ? Maintenant que le problème de l’invite de connexion est résolu, je pourrais envisager de mettre en œuvre l’idée que mon équipe avait auparavant, en utilisant de faux e-mails et un serveur SMTP que nous gérons et qui mappe ces faux e-mails au vrai e-mail d’un utilisateur. Par exemple, nous mettrions à jour l’e-mail Discourse de chacun vers quelque chose comme userid@example.com, qui se connecte d’abord à notre serveur SMTP et prend le userid pour rechercher le vrai e-mail de l’utilisateur. Cependant, ce n’est pas quelque chose que nous aurions prêt avant un certain temps, nous aurions donc besoin de mettre à jour les e-mails Discourse des utilisateurs plus tard si possible.
Oui. Vous devrez activer le paramètre du site auth overrides email pour cela. Lorsqu’il est activé, l’e-mail Discourse d’un utilisateur est synchronisé avec l’e-mail inclus dans la charge utile d’authentification (la charge utile DiscourseConnect dans votre cas) chaque fois que l’utilisateur se connecte. S’il n’est pas activé, l’e-mail de l’utilisateur sera défini sur l’e-mail de la charge utile d’authentification lors de la création initiale du compte, mais ne sera pas mis à jour lors des connexions ultérieures.
En supposant que auth overrides email est activé, vous pouvez également le mettre à jour sans obliger les utilisateurs à se connecter en effectuant une requête API vers la route sync_sso : Synchroniser les données utilisateur DiscourseConnect avec la route sync_sso.
Vous pourriez également mettre à jour les adresses e-mail des utilisateurs en masse depuis la console Rails du site, mais (je pense) le faire de cette manière déclenchera l’envoi d’un e-mail de confirmation de Discourse à l’utilisateur. Cela ne fonctionnera pas avec de fausses adresses e-mail.
Peut-être pourriez-vous simplement définir les e-mails sur quelque chose de significatif au départ. Une fois que vous aurez configuré un site Discourse, vous devriez faire quelques tests pour voir quels domaines d’e-mail Discourse acceptera pour les faux e-mails. De mémoire, je pense que @invalid.com est accepté. Je ne suis pas sûr pour les autres domaines. De votre côté, vous pourriez mapper quelque chose comme <userId>@invalid.com à l’adresse e-mail réelle de l’utilisateur.
Vous avez été incroyablement utile, merci beaucoup ! La solution API est ce que j’avais en tête, mais savoir qu’elle peut se synchroniser elle-même fonctionne aussi parfaitement.
Nous pourrions, oui. J’allais d’abord essayer d’utiliser l’adressage plus, de cette façon au moins certains utilisateurs recevraient toujours des e-mails dès le début. Ensuite, nous passerions à notre propre serveur de mappage SMTP plus tard pour prendre en charge tout le monde, y compris ceux pour qui l’adressage plus n’a pas fonctionné.
1 « J'aime »
@simon @supermathie Vous deux avez été incroyablement utiles jusqu’à présent, j’espère que je peux sortir légèrement du cadre de ce fil de discussion et demander de l’aide supplémentaire ?
J’ai installé Discourse sur une machine locale pour des tests, en utilisant Install Discourse for development using Docker comme guide. Je n’ai pas réussi à trouver d’autres guides sur la façon de le configurer pour les tests locaux ? Le wiki ne semble couvrir que les configurations de production, qui nécessitent que votre domaine/DNS/SMTP soient déjà configurés. Nous ne voulions pas exposer le forum au public tant que tout n’était pas implémenté de notre côté, nous avions donc besoin de tests locaux où rien de tout cela n’était requis.
Je l’ai mis en place et opérationnel en utilisant ce guide, et j’ai implémenté le SSO sur une instance locale de notre site, mais j’ai rencontré 2 problèmes jusqu’à présent :
- La redirection vers
return_sso_urlne semble fonctionner qu’à moitié ? Dans mon cas, l’URL esthttp://localhost:3000/session/sso_login. Elle redirige avec succès, cependant après la redirection initiale, elle m’envoie vershttp://localhost:3000, qui affiche simplement l’erreurRuntimeError: Discourse does not support compiling scss/sass files via Sprockets. Le seul fil de discussion que j’ai pu trouver à propos de cette erreur est Error when building: discourse does not support compiling scss/sass files via sprockets, mais cela ne semble pas avoir vraiment abouti. L’OP n’a accepté aucune solution, et la seule chose qui s’est produite a été de poser des questions sur les tailles de RAM et de swap (la machine sur laquelle cela fonctionne a 32 Go de RAM et 2 Go de swap. Je doute donc que ce soit le problème ?) avatar_force_updatesemble ne pas être respecté ? Ou du moins, pas pour les utilisateurs administrateurs ? J’ai activédiscourse connect overrides avatardans les paramètres du site, et dans la charge utile de réponse SSO, je définis à la foisavatar_urletavatar_force_update. Mais lors de la connexion au compte administrateur (qui est lié à mon compte externe), mon image de profil externe ne s’affiche pas ? Je peux voir queexternal_avatar_urlest correctement défini lorsque je vérifie les données de l’administrateur via l’API, il ne semble tout simplement pas être utilisé dans l’interface utilisateur ?
Il y a une liste de méthodes d’installation ici : Set up a local Discourse Development Environment?. J’ai un site de développement non-Docker (en utilisant le guide Ubuntu). Si c’est possible pour vous, je pense que vous obtiendrez les meilleurs résultats avec l’approche non-Docker. L’une des raisons pour lesquelles je l’utilise est de ne pas avoir à gérer les problèmes de réseau pour les requêtes API entre Discourse et d’autres applications que je développe localement. C’est aussi plus rapide que Docker.
Ça devrait l’être. Assurez-vous que l’application sur laquelle vous générez la charge utile SSO ne convertit pas la valeur booléenne true en 1. C’est un problème courant. Pour contourner cela, vous pouvez définir toutes les valeurs booléennes dans la charge utile SSO sur les chaînes \"true\" ou \"false\". Discourse les interprétera correctement. Vérifiez cela d’abord pour voir si c’est le problème. Ça pourrait être autre chose. Le code qui gère avatar_force_update est assez complexe, mais lisible : discourse/app/models/discourse_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub.
Edit : Pour le problème des valeurs booléennes dans la charge utile SSO, je suppose qu’il est plus exact de dire que dans le processus de génération de la charge utile SSO, l’environnement va convertir les valeurs booléennes true/false en chaînes de caractères. Discourse s’attend à ce que les chaînes soient \"true\" ou \"false\", d’autres environnements de programmation peuvent les gérer différemment. Par exemple :
PHP :
wp> strval(true)
=> string(1) "1"
Contrairement à Ruby :
irb(main):001> true.to_s
=> "true"
Python (je ne suis pas sûr de la façon dont Discourse gère cela) :
>>> str(True)
'True'
2 « J'aime »
Je vais essayer l’une de ces solutions. Merci de m’avoir orienté dans cette direction. C’est cependant assez contre-intuitif. Généralement, les gens recherchent la solution Docker comme méthode “rapide et facile” pour tout mettre en place. C’est la première fois qu’on me recommande d’ éviter la version Docker. Cela soulève tout de même la question de savoir pourquoi cela se produit avec la version Docker ? Utiliser une autre méthode d’installation pour contourner le problème fonctionne pour l’instant, mais cela ne résout pas le problème sous-jacent.
Elle n’est absolument pas définie sur 1. Je travaille en JavaScript, et la valeur booléenne true sera toujours convertie en chaîne de caractères \"true\" :
String(true); // 'true'
(true).toString(); // 'true'
// C'est ce que mon code utilise réellement
querystring.stringify({
avatar_force_update: true
}); // 'avatar_force_update=true'
Je n’ai jamais travaillé avec Ruby auparavant, donc je ne suis pas sûr de pouvoir vraiment approfondir le sujet. Mais d’après un aperçu, je ne vois aucun problème ? Cependant, j’ai bien vérifié que le paramètre pertinent dans le tableau de bord Discourse et dans la charge utile SSO sont tous deux définis :
Je n’ai pas testé si je pouvais changer l’image d’un compte utilisateur standard à autre chose que ce avec quoi le compte a été créé, mais lorsque je me suis connecté à un compte utilisateur standard pour la première fois, Discourse a téléchargé l’avatar et l’a appliqué comme prévu. Le seul compte qui n’est pas mis à jour est le compte administrateur ?
Pour être honnête, en PHP, on utiliserait presque toujours var_export pour obtenir la représentation textuelle “réelle” d’une variable, car elle renvoie le code PHP valide nécessaire pour recréer ladite variable :
var_export(true); // true
1 « J'aime »
Regardez la section DiscourseConnect qui se trouve en bas de la page d’administration de l’utilisateur. Il y a un bouton sur lequel vous pouvez cliquer pour afficher les valeurs de la dernière charge utile SSO reçue par Discourse.
Vous pouvez également trouver les mêmes informations à partir de la console Rails. Par exemple :
>SingleSignOnRecord.last
# ou
>SingleSignOnRecord.where(external_id: 2)
Vous devriez activer le paramètre du site verbose discourse connect logging. Cela ajoute des détails supplémentaires aux journaux générés dans Admin / Logs / Error Logs. Pour le problème d’avatar, il est possible que les entrées de journal pertinentes apparaissent comme des journaux d’erreurs normaux, et non comme des journaux DiscourseConnect.
Il est possible que le problème soit spécifique à WordPress. Il renvoie toujours 1 pour true et \"1\" pour la représentation sous forme de chaîne de caractères de true.
1 « J'aime »
C’est la charge utile attendue, et l’URL de l’image de profil s’affiche correctement :
L’image de profil DEVRAIT être celle-ci :
Cependant, elle s’affiche toujours comme suit :
Ce qui est mon Gravatar :
À moins que je ne comprenne mal ce paramètre, ou qu’il y ait autre chose que je doive également configurer, j’ai activé le paramètre pour les remplacer :
J’ai également essayé cela en mode incognito, avec différents navigateurs et en vidant le cache de mon navigateur pour exclure un problème de mise en cache.
Ceci est sur votre site de développement local ?
Je me demande si le téléchargement de l’avatar a échoué pour une raison quelconque. Essayez d’activer le paramètre du site verbose discourse connect logging (journalisation détaillée de discourse connect), puis déconnectez-vous et reconnectez-vous. Il devrait y avoir au moins un message dans les journaux lié à l’avatar :
Il y aura peut-être une autre erreur liée à l’échec du téléchargement.
Au cas où vous ne l’auriez pas encore compris, cela signifie : « vous devez y accéder via le proxy ember-cli au lieu d’un navigateur directement ».
Utilisez bin/ember-cli -u pour le lancer en développement.
J’ai reproduit votre situation d’avatar :
avant :
charge utile de connexion :
après :
mais :
Je pense qu’il s’agit d’un bug où Discourse définit correctement l’URL de l’avatar personnalisé mais ne passe pas de Gravatar à l’image personnalisée.
Si je crée un nouvel utilisateur :
cela fonctionne immédiatement :
je soupçonne donc que cela est déclenché par le fait d’avoir un compte avec un gravatar défini avant d’utiliser DiscourseConnect.
2 « J'aime »
J’ai réussi à faire fonctionner les étapes d’Ubuntu (après pas mal de retouches, car le script d’installation entrait en conflit avec les packages et logiciels que j’avais déjà installés). Cela a résolu l’erreur d’origine, mais l’authentification unique (SSO) ne fonctionne toujours qu’à moitié. Au lieu de l’erreur scss/sass, l’authentification unique affiche maintenant Account login timed out, please try logging in again. à chaque fois. Cliquer sur le bouton Login une seconde fois sur cette page d’erreur complète la connexion, cependant. Aucun changement de code n’a eu lieu de mon côté, seulement la façon dont Discourse est exécuté.
Je vais considérer tout cela comme des bizarreries de l’exécution locale. J’espère qu’un déploiement en production n’aura pas les mêmes problèmes.
Cela n’a pas semblé avoir d’effet avec la version Docker. Le script se terminait sans aucune sortie, et rien ne semblait vraiment se passer du côté de Discourse. Cela va également à l’encontre des étapes listées dans le guide Docker, ce qui est étrange. Y a-t-il une raison pour laquelle ce n’est pas mentionné ?
Il me semble étrange que la méthode Docker semble avoir ces problèmes, et que le conseil officiel soit d’installer Discourse nativement (malgré le fait que le script d’installation ne fonctionne pas toujours immédiatement, car il suppose des choses comme l’utilisation de bashrc et tente d’installer des versions potentiellement conflictuelles de packages déjà installés) ? Ne devrait-il pas y avoir un avertissement sur les problèmes potentiels avec toutes les versions d’hébergement disponibles ? D’un simple coup d’œil, il n’est pas clair laquelle choisir, et généralement les gens supposent que si une version Docker est disponible, c’est celle qu’il faut privilégier.
Heureux d’apprendre que je ne suis pas le seul ! 
Les bugs ne sont jamais amusants, mais je suis content d’avoir aidé à en trouver un.
C’est peut-être le cas, mais vous devriez pouvoir faire fonctionner DiscourseConnect localement sans aucun problème. Accédez-vous à Discourse à l’adresse http://localhost:4200 ? Il y a un problème étrange (à mon avis) où Discourse peut être accédé soit à localhost:4200, soit à 127.0.0.1:4200 dans un environnement de développement local. Je m’en tiendrais au domaine localhost. Il est traité comme une session différente de 127.0.0.1.
Quoi qu’il en soit, ce n’est qu’une supposition sur ce qui se passe. Assurez-vous d’activer le paramètre de journalisation détaillée et de consulter les journaux pour obtenir des détails.
Les instructions d’installation devraient indiquer clairement que vous n’avez pas besoin d’exécuter le script. Vous pouvez simplement suivre le script étape par étape pour vous assurer que toutes les dépendances sont installées.
Oui.
Ceux qui sont liés précédemment ne le précisent pas. Je suis allé sur Set up a local Discourse Development Environment?, et j’ai sélectionné Install Discourse on Ubuntu or Debian for Development car j’utilise Ubuntu 22.04.3. Cette page indique que vous n’avez pas à exécuter l’intégralité du script, mais seulement en petit texte après la partie qui demande aux utilisateurs de l’exécuter.
Pour moi, ce n’était pas clair, car en lisant les instructions de haut en bas, on supposerait naturellement qu’il faut terminer l’étape en cours avant de continuer. J’ai donc lutté contre le script d’installation, n’installant que ce dont j’avais besoin, pour ensuite continuer à lire après avoir terminé et voir que c’était prévu depuis le début et que je n’avais pas à me battre avec quoi que ce soit.
Placer cet avertissement après les instructions ne les rend certainement pas claires, à mon avis.
1 « J'aime »
Il semble qu’il pense que le nonce est incorrect ? Je vois ceci dans les journaux maintenant lors de la connexion :
Impossible de vérifier l'authenticité du jeton CSRF. 15:44
Journal SSO détaillé : Début du processus SSO add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 15:44
Journal SSO détaillé : Le nonce est incorrect, a été généré dans une session de navigateur différente ou a expiré add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784 15:44
Journal SSO détaillé : Début du processus SSO add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 15:44
Journal SSO détaillé : L'utilisateur s'est connecté sur PN_Jon add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784406/normal_face.png bio: card_background_url: confirm 15:44
MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-City.mmdb) introuvable : No such file or directory @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-City.mmdb 15:44
MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb) introuvable : No such file or directory @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb 15:44
Après une inspection plus approfondie, il semble que ce soit parce que la redirection SSO n’utilise pas localhost. Elle me renvoie vers 127.0.0.1. Si j’utilise 127.0.0.1 initialement au lieu de localhost, le problème est résolu.