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.
También me gustaría poder volver a mi cuenta de usuario cuando termine de suplantar. Esto es posible con todas las implementaciones que he utilizado para esta función en WordPress.
Estoy de acuerdo, no es esencial pero es un gran cambio y no creo que poner un banner en la parte superior con el botón de cerrar sesión sea tan complicado… probablemente podríamos hacer un plugin pero seguramente un cambio simple en el núcleo sería mejor.
Me pregunto si toda esta función necesita una reconsideración.
Impersonate siempre fue una herramienta muy útil que se implementó como una especie de hack.
Una implementación no hacky puede ser significativamente menos espeluznante y mucho más fácil de justificar como una función predeterminada que tiene Discourse.
Cuando estás suplantando a un usuario, solo tienes una vista de “solo lectura” (a menos que se habilite alguna configuración especial oculta del sitio).
Banner en la parte superior como sugirió @John_Lehmann.
Más ceremonia al suplantar, por ejemplo: un gran poder conlleva una gran responsabilidad.
En general, la función es muy útil para depurar cosas, pero actuar en nombre de otra persona es muy peligroso.
Me pregunto si, para empezar, @codinghorror tiene sentido hacer de la función actual “impersonate” una función que esté deshabilitada en los sitios de Discourse y que requiera cambiar una configuración oculta del sitio para habilitarla. ¿No estás seguro?
@sam de acuerdo, disculpa por la mención, pero he estado planteando esto al azar durante años y es un gran problema para algunos. La suplantación de identidad es la característica que hace que la privacidad del usuario sea una seria preocupación con Discourse, especialmente si se utiliza Discourse como plataforma interna (de trabajo) de comunicación y colaboración.
Lo hemos utilizado en el pasado y estamos recuperando una instancia de Discourse para usarla en nuestro sindicato. No para los miembros, sino para los oficiales electos. Durante el tiempo que administré la instancia anterior, fui un representante habitual como la mayoría. Ahora estoy en un puesto de liderazgo/administración del grupo, por lo que mi función en la organización no estaría en conflicto con las capacidades de un administrador de Discourse para ver todos los materiales dentro de todas las categorías. Pero entonces sí lo estaba…
Nuestro grupo ejecutivo tenía serias preocupaciones sobre un administrador que tuviera la capacidad de ver sus discusiones dentro de su categoría privilegiada (ejecutiva). Lo resolví de forma rudimentaria ocultándola a los miembros no ejecutivos con CSS (incluida la ocultación al administrador) y señalando cómo ver los registros para ver si alguna vez deshabilitaba el componente de tema específico llamado “privacidad del usuario”.
La otra GRAN preocupación era que un representante activo que fuera administrador de Discourse (de nuevo, en lugar de un técnico de TI contratado) pudiera suplantar a otro usuario, leer mensajes privados y manipular la configuración y los bienes personales de alguien.
Todo lo que puedo decir es que sería genial si hubiera una manera de centrarse en que los administradores no tengan privilegios de visualización global, sino más bien un acceso administrativo del sitio, que por defecto solo vea el contenido al que están asignados. Además, un sistema de notificación claro y designado para todos los usuarios que destaque si el personal administrativo está manipulando este tipo de cosas.
Llámenlo algo similar a los equipos de Discourse, tal vez Discourse profesional. Algo que no esté pensado tanto como un foro de Internet, sino más como una plataforma de colaboración y comunicación con conocimientos empresariales. Discourse brillaría en este rol, siempre que la capacidad de los ojos del administrador en todo pueda limitarse/restringirse o eliminarse. (principalmente la suplantación de identidad y la lectura de mensajes a través del perfil/la pestaña de mensajes).
Personalmente, no creo que tenga un gran deseo de suplantar a un usuario específico, sino más bien de suplantar un rol/miembro de grupo/nivel de confianza.
Encontré esto el otro día, donde tengo muchas categorías privadas que se me muestran como administrador, sin embargo, quería ver cómo se vería la lista de temas para alguien en un nivel T0, T1, etc.
Quizás esta función ya existe y está separada de la función de suplantación, supongo que más allá de esto, no estoy seguro para qué más usan la suplantación las personas.
Hay mucho sobre este tema en The Impersonated user should be notified that they are being Impersonated. Todavía estoy de acuerdo con las conclusiones a las que se llegó allí. En resumen, es una madriguera de conejo, los administradores pueden hacer de todo, si no confías en los administradores, no tengas administradores.
Quizás otro enfoque sería añadir algo de fricción a la suplantación mediante
añadir una ventana emergente de “estás seguro”, recordando que se registrará y que si solo quieren probar algo, pueden preferir crear un usuario de prueba y eliminarlo de nuevo cuando terminen. educación justo a tiempo, por así decirlo.
enviar el enlace para suplantar por correo electrónico (esto tendría el beneficio adicional de poder iniciar sesión en una ventana separada) similar a la descarga de copia de seguridad
También me gusta la idea de una configuración de administrador para deshabilitar la suplantación, deshabilitada por defecto. Ni siquiera necesita ser una configuración oculta, pero tener la configuración, como la restauración de copias de seguridad, reducirá el riesgo de que alguien se acostumbre a suplantar a otro usuario o lo haga por accidente.
Si tienen el control del sistema, tienen acceso a los datos. Necesitas administradores en los que puedas confiar, y tus usuarios deben ser educados de que no hay expectativa de privacidad. Eso es cierto para todo el software que se utiliza para la comunicación y la colaboración, incluso si se emplea cifrado en todas partes.
Ni siquiera puedes auditar realmente el acceso a las categorías y los mensajes privados; cualquier administrador decidido que sea un actor malintencionado con acceso root puede simplemente tomar una copia de seguridad del sistema de archivos y leerlos directamente de la base de datos.
Este es un gran punto. Probablemente todavía haya algunos casos en los que la suplantación sería útil, pero esto eliminaría casi por completo mi necesidad de suplantar a usuarios.
Cada vez que un usuario tiene algún problema extraño que el administrador o sus pseudousuarios no pueden encontrar o solo unos pocos usuarios lo informan.
La privacidad es una cuestión relativa. Afirmo que la mayoría de los foros se encuentran en una situación en la que un usuario no tiene información privada. Por lo tanto, la suplantación de identidad debería ser al menos una opción. Un aviso automático cuando sucede no es una mala idea en absoluto, incluso si es bastante innecesario, pero es una solución más abierta.
Una vez que esto sea estable, puedes imaginar impersonation_enabled_groups y hacer lo contrario: participar como un miembro normal, y solo ir a administrador cuando lo necesites… también conocido como modo sudo… Podría haber formas de cambiar de personalidad bajo demanda… Por ejemplo, Discourse Staff Alias limita la suplantación de identidad a un solo alias de equipo, pero al expandir la suplantación de identidad, uno podría cambiar de personalidad según varios criterios…
Por ejemplo, un miembro de @well-being.team podría publicar como un alias de grupo para desviar rencores personales, un autor podría publicar como @narrator o @characterN para escribir una historia interactiva, un maestro podría suplantar a un alumno para comprender su perspectiva… todo según grupos personalizables.
Una característica importante, supongo, sería que las sesiones de suplantación de identidad se registren adecuadamente y sean conocidas por el usuario suplantado.
Probé esta función experimental_impersonation y se ve bien. Hace lo que promete, y aprecio no tener que pasar por el engorro de cerrar sesión y volver a iniciar sesión como yo mismo.
@moin planteó en 🇩🇪 Fehler in der Deutschen Übersetzung? Hier melden! - #108 by Moin que “impersonate” y “stop impersonating” no se traducen bien al alemán. Es difícil encontrar las palabras adecuadas que capturen el significado completo de lo que estás haciendo. Este puede ser el caso de otros idiomas también, pero no lo he comprobado.
Me pregunto si queremos cambiar (juego de palabras intencionado) a términos más directos como Cambiar a @user_a_suplantar en la página de administración de usuarios y luego Cambiar de nuevo a @user_que_suplanto en el botón para dejar de suplantar. Eso probablemente sería más fácil de traducir y también más fácil de entender para los hablantes no nativos de inglés.
Las pruebas de hoy también descubrieron otros problemas:
Creo que debería haber una ventana modal para suplantar, similar a eliminar o fusionar. Esto te permite retroceder en caso de que presiones el botón accidentalmente, y también educa al administrador sobre lo que estás a punto de hacer, que se registrará y que podrás volver a cambiar sin tener que iniciar sesión de nuevo.
El hecho de que estás suplantando y volviendo a cambiar se registra en el registro de acciones del personal, pero las acciones que se toman mientras se suplanta no se registran. Creo que tendría sentido registrar eso también, dada la facilidad con la que esta función puede ser abusada, accidental o intencionalmente.
Todavía persiste un problema antiguo, que es que cuando suplantas a un usuario, se actualiza su fecha de última vista en la lista de usuarios y en la administración de usuarios, y (presumiblemente) en “quién está en línea” si ese plugin está instalado.
Me gusta esa idea de switch, porque en finlandés es igual de difícil encontrar una traducción adecuada. Tenemos una o dos palabras para eso, pero ninguna de ellas suena muy bien. Switch funcionaría perfectamente.
