Sometimes when I impersonate someone (albeit, not very often) I forget and keep trying to do admin type things and then realize I’m in someone elses account.
Another downside of the current process is that you have to click on the users avatar. I was impersonating a users that had 5 new notifications. When I clicked his profile, so I could log out of his account, it marks those notifications as read and no longer shows the (5) badge showing he has new notifications. How sad for him, when he returns! Hopefully he got some email notifications that will pull him back in!
Another community that I built and currently manage, is on the Higher Logic platform. I can’t tell you how much more I enjoy using Discourse than Higher Logic. But, now that I have that out of the way, I will say that I do like their method of impersonating users…
There’s a bar at the top of the screen, providing a constant visual reminder that you’re impersonating and a button to STOP, as well as a little orphan button at the bottom of the screen allowing you to STOP.
I don’t think they need both buttons. Top of the screen is sufficient.
I love @John_Lehmann’s suggestion with a more bold/obtrusive bar that stands out so you remember to get out of the user account before posting and doing other stuffs.
Not critical by any means.
I just came to meta, to see if there was a plugin for this, or something.
Just ended up needing this today. I use the impersonate feature to post category guidelines, or other pinned topics or replies in them under the @system account. What I currently do is post them under mine, then change ownership to @system, but what if someone has the topic set to watching, then they would see that it was me. I’m not necessarily trying to be anonymous when posting these, although, I just don’t want those posts under my name. I could make an alt whose purpose is to post these, although I would have to log in from a private window each time, which is bad ux.
J’aimerais également pouvoir revenir à mon compte utilisateur une fois l’usurpation terminée. C’est possible avec toutes les implémentations que j’ai utilisées pour cette fonctionnalité dans WordPress.
Je suis d’accord, ce n’est pas essentiel mais c’est un changement énorme et je ne pense pas que mettre une bannière en haut avec le bouton de déconnexion soit si compliqué… nous pourrions probablement faire un plugin mais un simple changement dans le cœur serait certainement mieux.
Je me demande si toute cette fonctionnalité nécessite une révision.
L’usurpation d’identité a toujours été un outil très performant implémenté comme une sorte de solution de contournement.
Une implémentation non-bidouille pourrait être beaucoup moins effrayante et beaucoup plus facile à justifier comme une fonctionnalité par défaut de Discourse.
Lorsque vous usurpez l’identité d’un utilisateur, vous n’avez qu’une vue en « lecture seule » (sauf si un paramètre de site spécial caché est activé).
Plus de cérémonie lors de l’usurpation d’identité, par exemple : avec un grand pouvoir vient une grande responsabilité.
Dans l’ensemble, la fonctionnalité est très utile pour déboguer des choses, mais agir au nom de quelqu’un d’autre est extrêmement dangereux.
Je me demande si, pour commencer, @codinghorror, il serait judicieux de faire de la fonctionnalité actuelle « d’usurpation d’identité » une fonctionnalité désactivée sur les sites Discourse et nécessitant de modifier un paramètre de site caché pour l’activer ? Pas sûr ?
@sam d’accord, désolé pour la notification, mais j’aborde ce sujet de manière aléatoire depuis des années et c’est un problème majeur pour certains. L’usurpation d’identité est la fonctionnalité qui fait de la confidentialité des utilisateurs une préoccupation sérieuse avec Discourse, surtout si vous utilisez Discourse comme plateforme interne de communication et de collaboration (au travail).
Nous l’avons utilisé par le passé et nous remettons en place une instance Discourse pour notre syndicat. Pas pour les membres, mais pour les dirigeants élus. Pendant que j’administrais l’ancienne instance, j’étais un représentant ordinaire comme la plupart. Je suis maintenant dans la direction/administration du groupe, donc mon rôle dans l’organisation ne serait pas en conflit avec les capacités d’un administrateur Discourse à voir tout le contenu de toutes les catégories. Mais ça l’était alors…
Notre groupe exécutif avait de sérieuses préoccupations quant à la possibilité pour un administrateur de consulter leurs discussions au sein de leur catégorie privilégiée (exécutive). J’ai résolu le problème de manière bancale en le cachant aux membres non exécutifs avec du CSS (y compris caché à l’administrateur), et en expliquant comment consulter les journaux pour voir si je désactivais le composant de thème spécifique appelé “confidentialité utilisateur”.
L’autre PRÉOCCUPATION MAJEURE était qu’un représentant actif qui est administrateur Discourse (plutôt qu’un technicien informatique sous contrat) puisse simplement usurper l’identité d’un autre utilisateur, lire des messages privés et trifouiller dans les paramètres personnels et les biens de quelqu’un.
Tout ce que je peux dire, c’est qu’il serait formidable s’il y avait peut-être un moyen de faire en sorte que les administrateurs n’aient pas de privilèges de visualisation globaux, mais plutôt un accès administratif plus limité au site, ne voyant par défaut que le contenu qui leur est attribué. De plus, un système de notification clair et désigné pour tous les utilisateurs afin de signaler si le personnel administratif s’occupe de ce genre de choses.
Appelez-le quelque chose de similaire aux équipes Discourse, peut-être Discourse professionnel. Quelque chose qui n’est pas tant un forum Internet qu’une plateforme de collaboration et de communication axée sur les affaires. Discourse EXCELLERAIT dans ce rôle, à condition que la capacité des administrateurs à tout voir puisse être limitée/restreinte ou éliminée. (principalement l’usurpation d’identité et la lecture des messages via l’onglet profil/messages).
Personnellement, je ne pense pas avoir un grand désir d’imiter un utilisateur spécifique, mais plutôt d’imiter un rôle/membre de groupe/niveau de confiance.
J’ai trouvé ceci l’autre jour, où j’ai de nombreuses catégories privées qui m’apparaissent en tant qu’administrateur, mais je voulais voir à quoi ressemblerait la liste des sujets pour quelqu’un d’un niveau T0, T1, etc.
Peut-être que cette fonctionnalité existe déjà et est distincte de la fonction d’imitation, je suppose qu’au-delà de cela, je ne suis pas sûr de ce que les gens utilisent d’autre pour l’imitation.
Il y a tellement de choses sur ce sujet dans The Impersonated user should be notified that they are being Impersonated. Je suis toujours d’accord avec les conclusions qui y ont été tirées. En bref, c’est une impasse, les administrateurs peuvent tout faire, si vous n’avez pas confiance dans les administrateurs, n’en ayez pas.
Peut-être qu’une autre approche serait d’ajouter une certaine friction à l’usurpation d’identité en :
ajoutant une fenêtre contextuelle « êtes-vous sûr ? », rappelant que cela sera enregistré et que s’ils veulent simplement tester quelque chose, ils préféreront peut-être créer un utilisateur de test et le supprimer à nouveau une fois terminé. éducation juste à temps, pour ainsi dire.
envoyer le lien pour usurper l’identité par e-mail (cela aurait l’avantage supplémentaire de pouvoir se connecter dans une fenêtre séparée ?) similaire au téléchargement de sauvegarde
J’aime aussi l’idée d’un paramètre d’administrateur pour désactiver l’usurpation d’identité, désactivé par défaut. N’a même pas besoin d’être un paramètre caché, mais avoir le paramètre, comme la restauration de sauvegarde, réduira le risque que quelqu’un prenne l’habitude d’usurper l’identité d’un autre utilisateur ou le fasse par accident.
S’ils ont le contrôle du système, ils ont accès aux données. Vous avez besoin d’administrateurs en qui vous pouvez avoir confiance, et vos utilisateurs doivent être informés qu’il n’y a aucune attente de confidentialité. C’est vrai pour tous les logiciels utilisés pour la communication et la collaboration, même si vous utilisez le chiffrement sur l’ensemble du système.
Vous ne pouvez même pas vraiment auditer l’accès aux catégories et aux messages privés, tout administrateur malveillant déterminé ayant un accès root peut simplement prendre une sauvegarde du système de fichiers et les lire directement dans la base de données.
C’est un excellent point. Il y aurait probablement encore quelques cas où l’usurpation d’identité serait utile, mais cela éliminerait presque entièrement mon besoin d’usurper l’identité d’utilisateurs.
Chaque fois qu’un utilisateur rencontre un problème étrange que l’administrateur ou ses pseudo-utilisateurs ne peuvent pas résoudre, ou que peu d’utilisateurs le signalent.
La vie privée est une question relative. Je prétends que la plupart des forums sont dans une situation où un utilisateur n’a aucune information privée. Ainsi, l’usurpation d’identité devrait au moins être une option. Un avis automatique lorsque cela se produit n’est pas une mauvaise idée du tout, même si c’est souvent inutile — mais c’est une solution plus ouverte.
Lorsque vous usurpez l’identité de quelqu’un et que vous avez terminé, vous devez vous déconnecter, puis vous reconnecter et terminer la 2FA si vous l’avez configurée.
Au lieu de cela, dans le menu utilisateur, il peut y avoir un bouton indiquant « Arrêter l’usurpation d’identité », et lorsque vous cliquez dessus, vous serez connecté à votre compte.
Personnellement, je pense que ce serait une fonctionnalité très utile lors de l’usurpation d’identité.
Une fois que ce sera stable, vous pourrez imaginer impersonation_enabled_groups et faire l’inverse : participer en tant que membre normal, et passer en mode administrateur uniquement lorsque vous en aurez besoin… alias le mode sudo… Cela pourrait permettre de changer de persona à la demande… Par exemple, le Discourse Staff Alias limite le pseudo-impersonation à un seul alias d’équipe, mais en élargissant l’impersonation, on pourrait être capable de changer de persona selon divers critères…
Par exemple, un membre de @well-being.team pourrait poster en tant qu’alias de groupe pour détourner des rancunes personnelles, un auteur pourrait poster en tant que @narrator ou @characterN pour écrire une histoire interactive, un enseignant pourrait usurper l’identité d’un élève pour comprendre sa perspective… le tout selon des groupes personnalisables.
Une fonctionnalité importante, je suppose, serait que les sessions d’impersonation soient correctement enregistrées et connues de l’utilisateur usurpé.
J’ai essayé cette fonctionnalité experimental_impersonation et elle semble bien fonctionner ! Elle fait ce qu’elle promet, et j’apprécie de ne pas avoir à passer par les étapes de déconnexion puis de reconnexion en tant que moi-même.
@moin a soulevé dans 🇩🇪 Fehler in der Deutschen Übersetzung? Hier melden! - #108 by Moin que « impersonate » et « stop impersonating » ne se traduisent pas bien en allemand. Il est difficile de trouver les bons mots qui capturent tout le sens de ce que vous faites. Cela pourrait être le cas pour d’autres langues aussi, mais je n’ai pas vérifié.
Je me demande si nous ne devrions pas passer (jeu de mots voulu) à des termes plus directs tels que Passer à @user_to_impersonate sur la page d’administration des utilisateurs, puis Revenir à @user_who_impersonated sur le bouton pour arrêter l’usurpation. Ce serait probablement plus facile à traduire et aussi plus facile à comprendre pour les non-francophones.
Les tests d’aujourd’hui ont également révélé d’autres problèmes :
Je pense qu’il faudrait une modale pour l’usurpation, similaire à la suppression ou à la fusion. Cela permet de revenir en arrière si l’on clique accidentellement sur le bouton, et informe également l’administrateur de ce que vous êtes sur le point de faire, que cela sera enregistré, et que vous pourrez revenir en arrière sans avoir à vous reconnecter.
Le fait que vous usurpiez une identité et que vous reveniez en arrière est enregistré dans le journal des actions du personnel, mais les actions effectuées pendant l’usurpation ne sont pas enregistrées. Je pense qu’il serait logique de l’enregistrer également, étant donné à quel point cette fonctionnalité est sujette aux abus, accidentels ou intentionnels.
Un vieux problème persiste, à savoir que lorsque vous usurpez l’identité d’un utilisateur, cela modifie sa date de dernière connexion dans la liste des utilisateurs et l’administration des utilisateurs, et (vraisemblablement) dans « qui est en ligne » si ce plugin est installé.
J’aime cette idée de switch, car en finnois, il est tout aussi difficile de trouver une traduction appropriée. Nous avons un ou deux mots pour cela, mais aucun d’eux ne sonne très bien. Switch fonctionnerait très bien.
