Problème avec WordPress Discourse SSO pour les utilisateurs connectés

Je travaille sur un site Web WordPress auquel est connecté un forum Discourse comptant environ 200 000 utilisateurs.
En utilisant les plugins OAuth Single Sign On - SSO (OAuth client) et WP-Discourse, nous connectons les publications de WP à Discourse et permettons aux utilisateurs de se connecter sur WP avec leur instance utilisateur WP, ce qui les connecte également à Discourse.

Maintenant, un problème est apparu, chaque fois que nous configurons les paramètres de Discourse pour qu’ils ne nécessitent pas d’être connecté.

Voici nos étapes :

  1. L’utilisateur se connecte à WordPress
  2. L’utilisateur clique sur un lien menant à Discourse (un sujet, n’importe quel lien menant à Discourse)
    ==> L’utilisateur voit maintenant Discourse comme s’il n’était pas connecté ! Mais il est connecté dès qu’il s’est connecté à WordPress !
  3. L’utilisateur clique maintenant sur la connexion Discourse ou sur n’importe quel lien de sujet
  4. La page se rafraîchit et l’utilisateur est maintenant authentifié !

On nous a dit que c’était attendu et que nous devions faire ce qui suit :

  • lorsque l’utilisateur est connecté, tous les liens menant à Discourse depuis WordPress doivent être les suivants : https://notre-instance-discourse.com/session/sso?return_path={URL D'ORIGINE DE DISCOURSE VERS LEQUEL NOUS POINTONS, comme une URL de sujet, ou autre}
  • lorsqu’un utilisateur est déconnecté, nous pouvons lier directement à {URL D'ORIGINE DE DISCOURSE VERS LEQUEL NOUS POINTONS, comme une URL de sujet, ou autre}, comme ceci https://notre-instance-discourse.com/t/slug-de-sujet

Je suspecte fortement que c’est la mauvaise approche pour résoudre ce problème, parce que :

  1. Et si un utilisateur, tout en étant connecté à Discourse, copiait l’URL d’un sujet et la partageait avec quelqu’un qui est également connecté à WP/Discourse ? Ils rencontreraient la même erreur que celle montrée ci-dessus au point n°2, car aucun suffixe d’URL de ce type ne serait ajouté.
  2. Pourquoi un utilisateur connecté aurait-il besoin d’être redirigé vers session/sso?return_path= ? Quelle est la raison technique et la logique derrière cela ?
  3. Pourquoi est-ce résolu dès que l’utilisateur rafraîchit la page (charge un sujet, clique sur connexion, etc.) ?
  4. Pourquoi cela n’est-il pas plus largement documenté, si c’était l’approche attendue ?
  5. Pourquoi cela ne serait-il pas mentionné dans l’API, où nous pouvons récupérer n’importe quelle URL de sujet de Discourse, et où il n’est NULLE PART écrit que les utilisateurs connectés ne pourront pas accéder immédiatement au contenu et devront d’abord effectuer des rechargements étranges, ou que nous devons ajouter des paramètres d’URL étranges qui, en fait, ne convertissent rien ?

J’apprécierais vraiment une opinion faisant autorité à ce sujet, car je ne suis pas du tout convaincu que ce soit le comportement attendu !
Si c’est le cas, j’aimerais demander :

  • pourquoi c’est réellement nécessaire et
  • qu’est-ce qui est prévu pour y remédier (car ce n’est certainement pas idéal, voir le point 1 de mes raisons pour lesquelles cela ne devrait pas être attendu)

Merci !

Bonjour @smileBeda,

Vous pouvez consulter la documentation ici :

Si vous souhaitez que vos utilisateurs soient automatiquement redirigés vers la connexion lorsqu’ils accèdent à n’importe quel chemin de votre forum, vous devrez activer le paramètre login required (connexion requise). C’est en effet le comportement attendu.

1 « J'aime »

Merci @angus pour cette confirmation.

Bien que cela semble toujours étrange, j’ai ajouté une redirection vers session/sso?return_path= lors de la connexion de l’utilisateur dans wp.
Le chemin de retour que j’ai défini est le référent de wp (s’il y en a) ou la page d’accueil de wp.

Cela fonctionne très bien et garantit que l’utilisateur est connecté aux deux instances.
J’ai dû activer le paramètre dans discourse pour autoriser “n’importe quel chemin de retour”, car par défaut, discourse interdit les chemins de retour “externes”.

Voyez-vous un problème à activer ce paramètre ?

Merci encore pour votre aimable réponse, votre confirmation “officielle” et le lien vers la documentation !

En général, je déconseille à mes clients de procéder à une redirection automatique comme celle-ci. Je comprends pourquoi vous considérez cela comme un problème, c’est un sentiment assez courant, cependant l’approche standard fonctionne très bien pour de nombreux sites, aussi grands, voire plus grands que le vôtre, et la redirection automatique peut ne pas fonctionner dans certains scénarios, entraînant une mauvaise expérience utilisateur.

La connexion unique qui vous permet de vous connecter automatiquement partout, comme vous l’attendez, est la façon dont les services interconnectés comme Meta (par exemple, se connecter à Facebook et être connecté à Instagram) fonctionnent parfois, car ce sont des plateformes centralisées (bien que même les services centralisés fonctionnent parfois de la même manière que DiscourseConnect).

En revanche, vous avez affaire ici à des frameworks logiciels open-source indépendants (c’est-à-dire Wordpress et Discourse). Ils peuvent être configurés pour fonctionner efficacement de la manière que vous attendez, mais cela nécessite un travail personnalisé spécifique qui tient compte de votre cas d’utilisation particulier. Ce ne sera jamais la façon dont un système d’authentification comme DiscourseConnect, qui sert des milliers de cas d’utilisation différents, fonctionne.

Non, avec la réserve que je remettrais en question la nécessité de l’avoir. Mais sans plus d’informations, je ne vois pas de problème à l’utiliser.

1 « J'aime »

Cela pourrait-il être un risque de redirection non validée, tel que décrit ici ?

Je peux voir comment « autoriser toute valeur de retour » permet effectivement de rediriger n’importe où.
Mais je ne suis pas sûr que ce soit vraiment un risque, car aucune donnée sensible n’est partagée dans ou vers cette URL de redirection.

Merci !

@Angus - auriez-vous une idée sur le dernier doute ci-dessus ?

Merci !

Désolé, cela reviendrait à vous donner des conseils sur une partie sensible de votre configuration sans l’avoir vue moi-même, ou sans avoir de relation définie avec vous.

Compte tenu notamment de la taille de votre forum et des réglementations applicables, je vous recommande de demander des conseils spécifiques et éclairés sur cette question.

Peut-être n’était-ce pas clair :

  1. Un forum Discourse active le réglage dans Discourse pour autoriser « tout chemin de retour ».
  2. Cela signifie que vous pouvez maintenant visiter votre-domaine.tld/session/sso?return_path=N’IMPORTE QUOI
  3. N’IMPORTE QUOI peut être une URL externe.

Ainsi, cela ouvre une vulnérabilité de sécurité dans la mesure où au moins une tentative de phishing pourrait être mise en scène :

  • un site web malveillant crée un bouton disant « allez à la communauté incroyable ! »
  • le lien du bouton est votre-domaine.tld/session/sso?return_path=RETOUR AU SITE MALVEILLANT
  • l’utilisateur clique sur le bouton, se connecte à la communauté, ce qui le ramène au SITE MALVEILLANT
  • là, l’acteur malveillant a implémenté une page qui ressemble exactement à la communauté et dit « quelque chose s’est mal passé lors de votre connexion, veuillez réessayer »
  • l’utilisateur soumet un formulaire de connexion d’apparence soignée qui correspond à l’apparence de la communauté.

L’acteur malveillant a-t-il maintenant capturé les données de connexion ?

Ainsi, probablement, le réglage « tout chemin de retour » ne devrait jamais être utilisé pour un site où les utilisateurs se connectent, à moins que chaque utilisateur ne sache exactement à quoi faire attention.

Verriez-vous aussi ce risque ?
Pourquoi les développeurs de Discourse créant des plugins/codes qui peuvent interagir avec ce réglage ne pourraient-ils pas donner un signe dans le sens de « oui pas de problème » ou « enfer non » ?
Il n’y a pas beaucoup de choses qui peuvent changer dans ce paramètre d’URL. Il est soit là, soit pas là, soit il autorise les externes, soit pas.

Peut-être que je m’aventure dans un domaine où je ne devrais pas, dans le sens de « ne pas discuter des problèmes de sécurité ici » ? Je comprendrais cela bien sûr, de nombreuses plateformes n’autorisent pas à parler ouvertement des problèmes de sécurité potentiels qui ne sont pas clairement définis lors de leur activation :slight_smile:

Je pense que vous avez déjà répondu à votre propre question.

Parce que la valence des paramètres dépend de la façon dont ils sont utilisés, c’est d’ailleurs pourquoi ce sont des paramètres et pas juste des « fonctionnalités ». S’il y avait une réponse simple à votre question, il n’y aurait pas de paramètre en premier lieu.

J’apprécie que cette réponse quelque peu juridique soit frustrante. Mais vous avez besoin de conseils spécifiques à votre cas d’utilisation, ce que je ne suis pas en mesure de vous donner ici.