En utilisant le point de terminaison /admin/users/sync_sso pour synchroniser les données SSO, il n’est pas possible de supprimer le nom d’un compte, même si cela n’est pas requis. Autrement dit, il n’est pas possible de passer le nom d’un compte d’une valeur quelconque à rien. Cela se produit avec full_name_required = false (et sso_overrides_name = true).
Je pense que le problème se situe ici :
mais je crains que mes connaissances en Ruby/Discourse ne soient pas suffisantes pour soumettre une PR.
Cela ressemble à une demande de fonctionnalité. Pour le moment, vous pouvez utiliser l’API d’administration pour effacer des noms dans des cas comme celui-ci. Voir :
Désolé, mais je ne suis pas d’accord. Je ne vois pas comment cela peut être une demande de fonctionnalité et non un bogue.
Je comprends qu’il existe d’autres points de terminaison d’API utilisables. Mais l’objectif principal de /admin/users/sync_sso est précisément de maintenir ce type de données, eh bien, synchronisées. Il permet déjà de définir le champ nom du compte — cela fonctionne. Cependant, il suppose que le nom est toujours un champ obligatoire et ne permet pas de le laisser vide. Il ne peut donc pas être utilisé pour maintenir les données synchronisées.
Le code ci-dessous semble fonctionner comme prévu dans mon bac à sable, mais encore une fois, je ne me sens pas assez confiant pour soumettre une PR pour le moment. N’hésitez pas à l’utiliser, l’adapter, etc.
- if SiteSetting.sso_overrides_name && user.name != name && name.present?
- user.name = name || User.suggest_name(username.blank? ? email : username)
+ if SiteSetting.sso_overrides_name && user.name != name
+ if SiteSetting.full_name_required && name.present?
+ user.name = name || User.suggest_name(username.blank? ? email : username)
+ else
+ user.name = name
+ end
Une fois de plus, je ne connais pas assez les détails internes (ni Ruby)… mais est-il impossible de savoir si le champ name a été fourni dans cette requête ? S’il n’est pas présent du tout, ne pas toucher au champ name du compte. S’il est fourni, le définir (s’il est vide, le vider). Cela ne respecterait-il pas ce protocole/comportement où seuls les champs fournis sont synchronisés ?
Désolé si cela n’a pas de sens — je tente simplement de comprendre à partir de ce que je sais.
Le problème est que la sémantique du protocole pour le paramètre « name » est désormais telle que, s’il est présent mais défini à une chaîne vide, cela équivaut à l’absence du paramètre « name ». Il ne fait simplement aucune modification.
Un changement ici constitue une modification de la sémantique du protocole. On pourrait, je suppose, modifier le comportement de sorte que name= signifie « effacer le nom », tandis que l’absence de name signifie « ne pas toucher au nom ». Cependant, les utilisateurs s’appuient déjà sur l’ancien comportement, ce qui en fait techniquement une modification incompatible.
Pouvez-vous expliquer pourquoi vous supprimez les noms ?
Nous ne supprimons pas les noms de tout le monde — les utilisateurs mettent à jour leurs propres données lorsqu’ils modifient leur compte sur notre site web (fournisseur SSO). Nous nous appuyons sur /admin/users/sync_sso pour maintenir la synchronisation des données (nom d’utilisateur, nom, avatar, etc.) dans leur compte Discourse. Le champ nom est facultatif et peut être laissé vide.
Je viens de réaliser que le problème ne concerne pas uniquement le nom, mais aussi la mise à jour de la biographie, de l’avatar, etc. : il n’est pas possible de synchroniser ces enregistrements SSO via /admin/users/sync_sso lorsqu’ils doivent être mis à jour pour être vides, qu’ils soient des champs obligatoires ou non.
Je comprends l’argument selon lequel les utilisateurs pourraient dépendre du comportement existant (bien que personne n’ait signalé ce problème auparavant ?), mais si tel est le protocole, il semble présenter des limitations significatives par rapport à son objectif de synchronisation des enregistrements SSO.
Je suis également confronté à ce problème : les utilisateurs individuels ne peuvent pas supprimer leurs propres informations personnelles (nom, avatars, bio, champs personnalisés, etc.) de Discourse, ce qui a des répercussions, comme vous pouvez l’imaginer.
Je suis d’accord pour ne pas modifier la sémantique du fonctionnement actuel, mais ne pourriez-vous pas nous permettre de définir ces attributs à false dans la charge utile SSO, ou quelque chose de similaire, pour être explicite quant à leur suppression ?
Auparavant, nous contournions cette limitation SSO en composant l’appel à /admin/users/sync_sso avec un autre appel au point de terminaison /u/{username} juste pour effacer le nom (si la nouvelle valeur pour le nom était vide).
Cependant, cela semble également avoir cessé de fonctionner à un moment donné dans une version récente, peut-être parce qu’il vérifie si sso_overrides_name = true avant de mettre à jour le nom.
Ainsi, tel quel, lors de l’utilisation de SSO et sso_overrides_name = true, il semble désormais impossible pour le fournisseur SSO d’effacer le champ nom sur Discourse via l’API.
Je suppose qu’un paramètre supplémentaire pour notre route sync_sso est nécessaire ? Quelque chose comme &clear_name pas sûr. Cela ressemble à un cas limite. Quel est le cas d’utilisation pour les noms vides ? Peut-être le définir simplement sur le nom d’utilisateur si vous n’en avez pas et que l’interface utilisateur peut supprimer les doublons.
Cela me trouble que vous considériez cela comme un cas limite, j’imagine donc que vous êtes habitué à des cas où le nom est le champ requis.
Nous avons l’inverse : le nom d’utilisateur est ce que tout le monde doit avoir, et le nom est un champ facultatif (nous utilisons prioritize_username_in_ux = true et full name required = false). Pensez aux comptes Twitter, où tout le monde doit avoir un nom d’utilisateur/pseudo, et peut éventuellement avoir un nom aussi. Je ne pense pas que vouloir effacer le champ nom (ou d’autres données personnelles) soit un scénario limite.
Actuellement, une fois qu’un nom a été saisi, il est impossible de le supprimer. C’était une limitation de sync_sso que nous avons contournée avec un appel API supplémentaire pour mettre à jour l’utilisateur, mais maintenant cela ne fonctionne plus non plus.
Nous l’avons envisagé, mais cela amène certaines personnes à supposer que le nom d’utilisateur est aussi le nom réel : nous gérons un forum international et il n’est souvent pas clair de savoir ce qui est le nom d’une personne et ce qui est un nom d’utilisateur (autre que leur position dans l’interface).
Je dois mentionner que si ma mémoire est bonne, le même problème exact se produit avec la suppression de l’avatar via sync_sso, car je pense que cela ne fonctionne pas non plus — nous contournons cela en fournissant notre propre URL pour un avatar par défaut.
S’il y a plusieurs champs qu’on ne peut pas effacer d’une manière ou d’une autre, peut-être un tableau (ou une liste csv) des champs à effacer/réinitialiser ?
Qu’est-ce qu’il faudrait pour parvenir à un accord sur la manière d’y parvenir ? Je suis heureux de mettre en œuvre quoi que ce soit de mon côté : un nouveau paramètre, une valeur spéciale, un deuxième appel API. Mais la situation actuelle, de mon point de vue, n’est pas un cas extrême. Comme @mentalstring ci-dessus, je synchronise avec une source de vérité externe où la définition d’une photo de profil et d’un nom d’affichage sont facultatives. L’utilisateur est autorisé à ne pas les avoir. Discourse leur permet de ne pas être définis. Si vous n’utilisez pas le SSO, vous pouvez les définir et les supprimer librement. DiscourseConnect brise cela : une fois qu’ils sont définis, ils ne peuvent jamais être supprimés, ce qui est, à mon avis, un (très petit) bug.
Je comprends la préoccupation concernant la modification du protocole où vide signifie actuellement aucun changement. Personnellement, je ne suis pas d’accord, je pense que c’est une manière simple et raisonnable d’interpréter le protocole et le risque est minime : il serait très étrange que des systèmes soient implémentés de telle sorte qu’ils envoient toujours les valeurs name et avatar_url, mais les définissent parfois à vide, et s’attendent à ce que cela signifie conserver l’ancienne valeur. Et s’il y en a qui le font, la conséquence est seulement que le nom et l’avatar sont désactivés, et ce devrait être une correction facile.
Mais bref, je ne veux pas argumenter sur ce point, mais je veux soutenir que c’est une fonctionnalité nécessaire. Je suis prêt à faire le PR, je veux juste savoir quelle solution serait acceptée.
Étant donné que cela se produit avec au moins name et avatar_url et potentiellement d’autres (je pense aussi à website ?), peut-être un paramètre reset_fields avec une liste de champs à effacer au lieu de plusieurs clear_x individuels ?
Pour nous, il serait déjà utile de pouvoir corriger cela avec des appels supplémentaires au point de terminaison /u/{username}, mais cela aussi a cessé de fonctionner à un moment donné.