Nous espérons avoir une communauté où l’on n’obtient un compte que dans le cadre de notre processus d’enregistrement de produit, mais nous voulons rendre le contenu du forum visible afin que les personnes qui essaient de s’auto-aider via Google puissent obtenir un résultat approprié tout en étant non authentifiées. (également pour que nous puissions potentiellement atteindre certains objectifs de référencement pour notre contenu)
Est-ce possible ou est-ce un rêve ? Il semble que je ne sois pas la première personne à poser cette question, ou à désirer cette capacité de produit.
Le problème est donc que certains utilisateurs seront connectés à votre Cognito et que vous ne voulez pas qu’ils voient une boîte de dialogue de connexion s’ils essaient de répondre ? Je pensais qu’avec Discourse Connect, c’était le comportement par défaut.
Vous pouvez rendre le site ouvert aux utilisateurs anonymes et à Google.
Dans un monde idéal, un utilisateur consultant Discourse qui a un compte devrait être connecté à tout moment, cela nous permet de capturer toutes ses données de consultation. Je vais faire en sorte que si un utilisateur d’un produit clique sur un lien dans le produit pour consulter la communauté, il sera authentifié, ainsi que tous les liens que l’utilisateur ne devrait voir que s’il est authentifié ailleurs (page de compte, par exemple).
Cependant, si un utilisateur tente de s’auto-aider via Google et arrive dans la communauté, nous ne pouvons pas capturer ces données tant qu’il n’essaie pas d’interagir directement avec la communauté, même s’il est authentifié ailleurs dans notre système. Il semble que la seule façon de résoudre ce problème soit d’activer le paramètre du site login_required, ce qui, si je comprends bien, rend le site privé.
Merci. Je ne le savais pas. Je suis un CM essayant de comprendre tous les tenants et aboutissants de trois produits distincts et cela me fait fondre le cerveau d’essayer de maîtriser les détails de chacun ! Attendez-vous à voir quelques autres messages de ma part pour tout régler, et je vous remercie de votre patience.
Dans le cas général, ce sera impossible (comment savoir si un utilisateur anonyme a un compte sans lui demander de se connecter ?). Cependant, il devrait être possible de détecter si un utilisateur a déjà une session active sur votre site SSO.
Ce sujet est assez ancien, mais je pense que le principe devrait toujours s’appliquer. En gros, ajoutez une URL avec un support CORS approprié qui renvoie une réponse JSON indiquant si l’utilisateur a une session active. Ensuite, ajoutez du JS à votre thème Discourse qui interroge cette URL et déclenche le processus SSO s’il existe une session active.
Je crains que la réponse générale ne soit toujours largement la même qu’à la dernière fois.
La spécification dont je parlais est OpenID Connect Session Management. Malheureusement, cette solution basée sur iframe devient de moins en moins utile car de nombreux navigateurs bloquent désormais les cookies tiers par défaut. Elle ne fonctionne de manière fiable que si votre fournisseur d’identité et Discourse ont la même « origine ».
Comme l’a dit @simonk, en fonction de votre fournisseur d’identité, il pourrait être possible d’implémenter quelque chose de personnalisé via un composant de thème, mais je ne connais aucune solution générale que nous pourrions ajouter à Discourse lui-même.
Vous avez tout à fait raison, cliquer sur « répondre » déclenchera le flux de connexion. Et si DiscourseConnect (ou tout autre fournisseur de connexion unique) est utilisé, la fenêtre modale de connexion Discourse sera ignorée
Cependant, je pense que l’auteur de la publication souhaite que les utilisateurs soient automatiquement connectés, sans avoir à cliquer sur « répondre » ou « se connecter ». Avec ce type de configuration, il serait totalement transparent pour les utilisateurs de passer du site principal à la communauté. Nous avons réalisé cela pour quelques clients, mais il s’agissait d’implémentations sur mesure qui ne peuvent pas être facilement généralisées.
Pour donner un exemple d’une approche : si votre forum est sur forum.example.com et que votre site principal est sur example.com, alors le forum est autorisé à lire les cookies de example.com. Ainsi, un composant de thème peut vérifier l’existence d’un cookie et faire quelque chose comme ceci :
const cookie = require("discourse/lib/cookie").default;
if(cookie('name_of_example_com_auth_cookie') && !api.getCurrentUser()){
// L'utilisateur a un cookie d'authentification pour example.com. Il est presque certainement
// connecté là-bas, alors exécutons le flux d'authentification
window.location = "https://forum.example.com/auth/oidc"
}
(diverses conditions s’appliquent ici. Par exemple, le cookie ne doit pas être http_only, ne doit pas être un cookie hôte uniquement, etc.)
C’est effectivement le cas. C’est bien de savoir que c’est possible, mais que c’est personnalisé.
De plus, comme j’ignorais qu’un utilisateur qui clique sur répondre pouvait sauter la boîte de dialogue de connexion selon l’implémentation, cela atténuera bon nombre de mes préoccupations initiales. C’est la principale barrière à l’entrée que je veux éviter, et je suis heureux que cela puisse être mis en œuvre.
Bien sûr, le passionné de données en moi veut la version idéale, et il est possible que nous aspirions à cela. Savoir que c’est possible pour l’instant est suffisant. Merci encore à tous pour votre temps.
