Validité des identifiants SSO / déconnexion forcée

[markwill (Mark Williams)]

Quelle durée de session dois-je prévoir avant que l’utilisateur ne soit invité à se reconnecter ?

J’ai implémenté mes propres fonctions de vérification dans functions.php, en les intégrant au plugin SSO pour WordPress. Ma logique semble assez simple, mais j’ai remarqué qu’un membre dont la carte de crédit a été refusée (ce qui a donc supprimé le tag utilisateur que ma logique vérifie) a pu accéder à mon forum aujourd’hui. Après vérification, elle s’est connectée il y a quelques jours et semble toujours être connectée. Sa dernière date de connexion sur WordPress remonte également à quelques jours.

Est-il normal que ses identifiants mis en cache continuent de fonctionner ? Si oui, existe-t-il un moyen de contrôler la validité du jeton et/ou de répondre à un webhook pour forcer une déconnexion ?

Merci.

[simon]

@markwill

Quelle durée de session dois-je prévoir avant que l’utilisateur ne soit à nouveau invité à se connecter ?

Ceci est contrôlé par le paramètre du site Discourse « âge maximum de session ». Il définit le nombre d’heures pendant lesquelles les utilisateurs resteront connectés à votre site. Par défaut, il est fixé à 1440 heures (60 jours). Vous pouvez essayer de réduire cette valeur. Si vous la fixez trop bas, vos utilisateurs pourraient penser qu’il s’agit d’un bug.

@markwill

Je viens de remarquer qu’un membre dont la carte de crédit a été refusée (et qui a donc perdu le tag utilisateur que ma logique vérifie) a pu accéder à mon forum aujourd’hui. Après vérification, elle s’est connectée il y a quelques jours et, je suppose, semble toujours être connectée.

Cela est logique. Vous pouvez déconnecter manuellement les utilisateurs en accédant à leur page d’administration Discourse et en cliquant sur le bouton « Se déconnecter » que vous verrez en haut à droite de la page. Une autre option pour contrôler cela consisterait à ajouter du code à votre site WordPress qui déconnecte les utilisateurs de Discourse lorsqu’un abonnement expire.

[markwill (Mark Williams)]

C’est très apprécié, Simon. Bien que je pense que 60 jours soient trop longs pour mes scénarios (il s’agit de membres payants, ils s’attendent donc à ce que nous vérifiions qu’ils sont toujours membres valides), je suis d’accord pour dire que le réduire trop peut être pénible.

La dernière suggestion (trouver un moyen de les déconnecter de Discourse lorsque leur adhésion prend fin) est celle que je vais étudier. J’avais vu l’option de déconnexion manuelle, mais je cherche à tout automatiser complètement, ce qui semble être la bonne voie.

Merci encore.

[mcwumbly (Dave McClure)]

@simon

Cela est contrôlé par le paramètre du site Discourse « âge maximal de session ». Il définit le nombre d’heures pendant lesquelles les utilisateurs resteront connectés à votre site.

Hmm… la description du paramètre du site indique (mise en évidence de ma part) :

L’utilisateur restera connecté pendant n heures depuis sa dernière visite

Si je comprends bien, l’utilisateur pourrait rester connecté indéfiniment s’il continue de visiter le site périodiquement, même après avoir perdu ses identifiants SSO. Par exemple, si le paramètre est réglé sur 72 heures, tant qu’il continue de visiter le site tous les jours ou tous les deux jours, il restera connecté. Est-ce que mon interprétation est correcte ?

[codinghorror (Jeff Atwood)]

Oui, c’est vrai d’après mon expérience. Il n’y a pas de délai d’expiration absolu qui force la déconnexion d’un utilisateur après une période fixe.

[markwill (Mark Williams)]

Donc, l’implication est que si quelqu’un annule mon abonnement et que je veux m’assurer qu’il ne peut plus accéder à mon forum, je devrai le déconnecter de force (manuellement ou via un appel API) ?

[sam (Sam Saffron)]

Oui, c’est la recommandation.

[markwill (Mark Williams)]

Merci. Ayant tout juste basculé depuis un groupe Facebook (qui nécessitait de retirer manuellement les membres lorsqu’ils annulaient leur abonnement), il est regrettable qu’avec Discourse, je doive toujours suivre un processus manuel pour m’assurer que les membres ayant annulé ne peuvent plus accéder à mon forum. Cela soulève une question.

Existe-t-il un mécanisme non manuel — aussi créatif soit-il — pour garantir qu’un utilisateur dont le compte n’est plus valide, c’est-à-dire qui ne peut plus se connecter, soit automatiquement déconnecté de Discourse ?

Il semble illogique que le mécanisme SSO empêche les utilisateurs de se connecter (en reconnaissant qu’ils n’ont plus de compte valide), mais s’ils accèdent simplement au forum régulièrement (moins que le délai d’expiration), ils peuvent y rester aussi longtemps qu’ils le souhaitent, jusqu’à ce que je les déconnecte manuellement.

Je pense que ma dernière option, potentiellement, serait d’écrire un plugin qui appellerait l’API de Discourse pour les déconnecter lorsqu’ils annulent leur abonnement.

Je suis ouvert à toutes et toutes les idées. Comme vous pouvez le constater, je VEUX VRAIMENT éviter de devoir faire cela manuellement

Merci.

[simon]

@markwill

Je suppose que ma dernière option, potentiellement, consiste à écrire un plugin qui appellera l’API Discourse pour les déconnecter lorsqu’ils annulent.

Vous pouvez effectuer une requête API vers /admin/users/<discourse_user_id>/log_out. Le plugin WP Discourse utilise cette route pour synchroniser la déconnexion de WordPress avec Discourse. Vous pourriez probablement copier la majeure partie du code de cette fonction : wp-discourse/lib/sso-provider/discourse-sso.php at main · discourse/wp-discourse · GitHub.

[markwill (Mark Williams)]

Très apprécié, Simon. Je vais jeter un coup d’œil.

Cependant, en prenant du recul, cela ne semble-t-il pas poser problème ? Je suppose que nous pouvons débattre de l’importance de cela, mais avoir une plateforme où les utilisateurs peuvent continuer à accéder à un forum indéfiniment, même lorsqu’ils n’ont plus de compte valide, est quelque chose que je n’ai jamais vu ailleurs.

Je peux peut-être accepter l’idée que c’est WordPress, et non Discourse, qui est la source de vérité ici. Cela pointe donc probablement vers le plugin SSO comme le meilleur endroit pour implémenter une telle logique.

Curieux de connaître la réflexion globale ici. J’aimerais penser que ce scénario est valide (déconnexion forcée après une certaine période ou lorsqu’un compte WordPress devient « invalide »), non ?

Je réfléchis simplement à voix haute, car j’aimerais éviter les étapes manuelles, mais aussi éviter d’écrire du code, si possible

[simon]

@markwill

Je peux peut-être admettre que c’est WordPress, et non Discourse, qui est la source de vérité ici. Cela pointe donc probablement le plugin SSO comme le meilleur endroit pour implémenter cette logique.

Oui, cela devra être géré par WordPress. Je pense qu’il serait logique que le plugin WP Discourse déconnecte les utilisateurs de Discourse lorsqu’ils sont supprimés sur WordPress, mais je ne suis pas certain que cela résolve votre problème. Mon hypothèse est que, lorsque l’abonnement d’un utilisateur expire sur votre site, celui-ci n’est pas supprimé de votre site WordPress. Pour gérer le cas de la déconnexion d’un utilisateur de Discourse lorsque son abonnement expire, vous devrez probablement ajouter du code à votre site qui se connecte à l’action déclenchée par votre plugin de gestion des abonnements lors de l’expiration d’un abonnement.

[markwill (Mark Williams)]

Merci encore, @simon. Tes arguments sont pertinents, mais pardonne-moi si je continue encore un tour

Il semble qu’il y ait deux facteurs en jeu ici : la validité d’un compte (à savoir, est-ce que l’utilisateur est un membre actif) et la validité d’un jeton dans Discourse.

Pour le premier point, je suis tout à fait d’accord pour que WordPress en ait la charge et, selon le temps disponible, je vais enquêter.

Cependant, il y a aussi la question d’un jeton actif/valide côté Discourse. Je comprends que cela puisse ne pas être une priorité absolue, mais je vois un certain intérêt dans une option (probablement désactivée par défaut) qui définirait une durée de validité pour la « connexion forcée », c’est-à-dire que le jeton de connexion de l’utilisateur expirerait après x jours, indépendamment du fait qu’il se soit connecté récemment ou non.

Encore une fois, je suis en mode brainstorming, mais je vois un certain intérêt à imposer une déconnexion en tant qu’option, indépendamment du fait que l’utilisateur possède un compte valide.

[Cardinalflyer (Keith Peterson)]

@simon

/admin/users/<discourse_user_id>/log_out

J’essaie de faire cela via un lien web, car je n’utilise pas WordPress. Est-ce que je devrais pouvoir le faire avec quelque chose comme ceci ?

https://community.mysite.com/admin/users/100004/log_out

Cela me renvoie une erreur 404 et l’utilisateur n’est pas déconnecté.

Si je parviens à faire fonctionner une URL, j’espère pouvoir forcer la déconnexion en utilisant une commande curl ou file_get_contents en PHP…

[simon]

@Cardinalflyer

J’obtiens une erreur 404 et l’utilisateur n’est pas déconnecté.

Vous devez envoyer une requête POST authentifiée vers la route. Vous pouvez configurer cela pour déconnecter les utilisateurs lorsqu’ils cliquent sur un lien, mais vous devrez gérer la demande côté serveur.

[Cardinalflyer (Keith Peterson)]

Merci ! Authentifié, hein ? En faisant quelques recherches là-dessus, il semble qu’un post authentifié depuis PHP envoie quelque chose comme ceci dans l’en-tête :

'Authorization: OAuth '.$accesstoken;

Il y a quelques indices ici et là que je continuerai à étudier.

Mais ce serait formidable si quelqu’un avait un extrait de code PHP fonctionnel ! L’exemple dans la section authentification de https://docs.discourse.org/ me renvoie une erreur de syntaxe… oh, attends, c’est une commande Unix !

Je serai ravi de recevoir tout indice qui pourrait m’aider pour PHP !

[simon]

@Cardinalflyer

Mais ce serait formidable si quelqu’un avait un extrait de code PHP fonctionnel !

Le lien de mon message précédent devrait suffire pour vous lancer : wp-discourse/lib/sso-provider/discourse-sso.php at main · discourse/wp-discourse · GitHub. En supposant que vous n’effectuez pas la requête depuis un site WordPress, vous devrez trouver un autre moyen d’effectuer la requête wp_remote_post.

[Cardinalflyer (Keith Peterson)]

Je pense que j’y suis presque, en utilisant de simples commandes PHP. Le code est ci-dessous. Le choix du nom d’utilisateur provient de ce post.

Je reçois cette réponse… est-ce que cela signifie quelque chose pour quelqu’un ? Cela semble être un problème de version de protocole SSL ?

error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

Voici mon code :

    $url = "https://community.mysite.com/admin/users/100004/log_out";
    $headers = array( 'Api-Key' => 'd412mylongadminkeyaadcd',
    				  'Api-Username' => 'system',
    				  );

	$ch = curl_init();
	curl_setopt($ch, CURLOPT_URL, $url);

[edit: j'ai ajouté ces lignes aussi, sans changement :]
	curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
	curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
[/edit]

	curl_setopt($ch, CURLOPT_POST, true);
	curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
    $data = curl_exec($ch);
    if (curl_errno($ch)) {
        echo curl_error($ch);
    }
    curl_close($ch);

[simon]

@Cardinalflyer

Je reçois cette réponse… cela signifie-t-il quelque chose pour quelqu’un ? Cela semble concerner une version de protocole SSL ?

Puisque vous utilisez WordPress, vous pouvez essayer d’effectuer la requête avec la fonction wp_remote_post. De cette façon, vous n’aurez pas à gérer les options curl.

[Cardinalflyer (Keith Peterson)]

Merci, mais je n’utilise pas WordPress. J’essaie de le faire en PHP dans un gestionnaire d’adhésions que j’ai construit moi-même au cours des dix dernières années.

[pfaffman (Jay Pfaffman)]

On dirait que votre bibliothèque PHP n’a pas accepté votre certificat HTTPS Discourse. Je ferais une recherche Google pour cette erreur.