Hemos tenido un grave problema de seguridad con el sistema de invitaciones. Supongo que es fácilmente reproducible. Nuestro sitio es solo por invitación. Además, hemos marcado “debe aprobar usuarios” en la configuración.
Uno de nuestros empleados emitió una invitación con un uso máximo superior a 1, por lo tanto, no restringida a un correo electrónico en particular (ejemplo a continuación).
Ese enlace de invitación circuló y la gente pudo registrarse con él. Sin embargo, esperábamos que cuando se marque “debe aprobar usuarios” en la configuración, el personal tendría que aprobar a cualquiera que usara esas invitaciones “sin restricciones de correo electrónico”. En cambio, todos fueron admitidos automáticamente, quienquiera que tuviera ese enlace. Por lo tanto, el enlace puede ser utilizado por cualquiera y no podemos verificar quién entra con él. Debemos poder realizar una “verificación de antecedentes”, utilizando la combinación del correo electrónico, nombre y otros campos que hemos agregado, que son campos obligatorios que pedimos para ser aprobados (después de que verifiquemos).
Esto creó un grave problema, ya que alguien de una organización extranjera estrictamente prohibida obtuvo ese enlace y se registró. Tuve que eliminar esa cuenta de inmediato. Es una falla grave para nosotros.
Por lo tanto, encuentro que la opción “debe aprobar usuarios” es peligrosamente engañosa. Actualmente, esa opción es inútil si tenemos una instancia solo por invitación.
¿Hay alguna forma de que el personal pueda aprobar a alguien que use el enlace de invitación que no ha sido restringido por correo electrónico? Esa parecería ser una forma lógica de tener habilitada la opción “debe aprobar usuarios” cuando el sitio es solo por invitación.
Puedo reproducir el problema: cuando se genera una invitación masiva, los usuarios que se registran con ese enlace son automáticamente inmunes a la configuración de “los usuarios deben ser aprobados”.
¿Viste algo en la documentación que te llevó a creer que las invitaciones que no estaban vinculadas a un correo electrónico añadían el paso de aprobación @Wall-E?
La clave aquí es que un miembro del personal emitió la invitación. Discourse lo trata como una aprobación implícita de los usuarios que utilizan la invitación.
Si un miembro que no es del personal generó la invitación, entonces el usuario que la canjeó se agregaría a la cola para que el personal la apruebe.
Entonces, si se utiliza una cuenta de usuario que no es de personal para crear una invitación, ¿las inscripciones a través de esa invitación pasarían a revisión? Si es así, es un comportamiento totalmente aceptable y @Wall-E podrías usar una cuenta normal ficticia para generar la invitación como solución alternativa.
Creo que debería haber al menos una advertencia para los usuarios del personal, y sería fantástico si pudieran elegir cómo se tratará a los nuevos miembros. Usar un segundo usuario “normal” sería una solución provisional fea.
Al leer este tema y los temas anteriores, puedo ver que el funcionamiento actual es “por diseño”, pero no refleja los nuevos cambios en el sistema de invitaciones. Se ha vuelto mucho más fácil crear enlaces de invitación que pueden ser utilizados por personas desconocidas. Los enlaces de invitación ahora también pueden ser creados peligrosamente por el personal que agrega invitados a grupos que pueden tener acceso a categorías seguras en el sitio.
@Wall-E Tengo curiosidad por entender cómo es que tus enlaces de invitación caen en manos de personas que no deberían tener acceso a tu sitio. Presumiblemente, el personal de tu sitio sabrá tener cuidado de no crear enlaces de invitación que cualquiera pueda usar y compartirlos públicamente o en entornos donde las personas equivocadas puedan usarlos. Hasta cierto punto, el problema que enfrentas es un problema de capacitación del personal. No dudes en enviarme un mensaje privado con tu respuesta si contiene detalles sensibles.
Si existen enlaces de invitación actualmente que de alguna manera están comprometidos, puedes eliminarlos y crear nuevos y compartirlos con más cuidado en el futuro. Como administrador, también siempre puedes buscar en la página de invitaciones al usuario para ver quién ha canjeado sus invitaciones. Si tienes personal en el que no confías, puedes bajar sus privilegios a TL4, que tiene privilegios de moderador cercanos.
Veo tres posibles cursos de acción:
No hacer nada. El sistema de invitaciones funciona según lo diseñado, el personal solo necesita tener cuidado con sus enlaces de invitación. Si tomamos esta ruta, sugiero cambiar la descripción de la configuración de administrador debe aprobar usuarios para que quede muy claro que los enlaces de invitación creados por los administradores omiten esta configuración.
El personal debe aprobar todas las cuentas de usuario nuevas antes de que se les permita acceder al sitio. Nota: las invitaciones creadas por el personal omiten esta configuración y no requieren aprobación.
Hacer (1) pero también agregar un paso de advertencia adicional de “estás seguro” cuando los administradores crean un enlace de invitación que se puede usar para obtener acceso inmediato al sitio. Solo en sitios con aprobación requerida.
Cambiar el comportamiento para que los enlaces de invitación creados por los administradores respeten la configuración de aprobación requerida al igual que las invitaciones de los no administradores.
Estoy de acuerdo con el OP en que el comportamiento actual es engañoso y tiene el potencial de causar problemas en los sitios cuando se requiere aprobación. Los sitios con esta configuración habilitada son extra cautelosos y necesitan este nivel adicional de control paranoico sobre quién puede obtener acceso.
Mi recomendación, por lo tanto, sería que elijamos la puerta número tres: hacer que todos los enlaces de invitación funcionen de la misma manera y respeten la configuración de debe aprobar usuarios.
Sin embargo, no creo que esto sea un error. Está funcionando según lo diseñado. Reclasificando como solicitud de características.
También estoy firmemente a favor de la opción 3. Estoy construyendo una comunidad donde las personas puedan reflexionar más profundamente sobre las emociones y creo que agregar ese nivel adicional de control a los enlaces de invitación anónimos (porque no están vinculados a una dirección de correo electrónico o identidad) podría hacerme sentir más tranquilo de que solo las personas que quiero que se unan lo harán.
Supongo que podría asegurarme de usar el correo electrónico de invitación en lugar del enlace de invitación anónimo, pero el enlace hace que sea mucho más fácil compartir en Whatsapp u otras plataformas de comunicación.
Por lo tanto, también estoy a favor de que los enlaces de invitación anónimos respeten la configuración de “debe aprobar usuarios”.
Además, creo que si sucede el #3, el sistema de invitación puede funcionar casi como un sistema de solicitud para foros solo por invitación. En este momento, no estoy seguro de cómo haría que las personas soliciten ser miembros sin tener un Google Form separado o algo similar. Esto podría optimizarlo de una manera, donde los campos de usuario personalizados podrían ser el formulario de solicitud, que es lo que creo que @Wall-E está tratando de hacer.
Eso no es de lo que trata mi tema. Estoy hablando de que must_approve_users no tiene ningún efecto en una instancia solo por invitación. Activarlo debería tener un efecto diferente que desactivarlo. Si no es así, entonces debería documentarse que este comportamiento no se aplica a una instancia solo por invitación. Si me lo perdí en la documentación, entonces es, de hecho, responsabilidad de nuestro personal. Pero si no lo está, entonces esa función es engañosa y debería arreglarse, o al menos documentarse, ya que ha engañado a todo nuestro personal.
Absolutamente. Podría haberme perdido en la documentación, si hubiera estado documentado, entonces sería mi responsabilidad haber engañado a mi personal, y una advertencia no vendría mal, porque la gente/el personal puede olvidar.
Voy a citar a los que tienen el poder de cerrarnos debido a ese aspecto, que se considera un problema de seguridad en nuestra organización: “Si este sistema puede permitir que alguien de una organización no autorizada entre, tienes que asumir que eventualmente lo hará, independientemente de tu diligencia”. Esto es exactamente lo que sucedió. Esa “característica” (diría yo, una no-característica ya que el “must_approve_user” simplemente no tiene efecto en el caso de invitación exclusiva) se habilitó, emitimos la invitación sin restricciones a las personas exactas que queríamos invitar, y obviamente, una de estas personas compartió ese enlace de invitación sin restricciones con otra organización.
Con esto también respondo a @tobiaseigen
Tenemos reuniones, conferencias, con a veces cientos de personas de organizaciones autorizadas que pueden unirse a nuestro foro. Pero algunas de ellas a veces son de otras organizaciones que no están autorizadas a unirse a nuestro foro (debido a políticas generales que escapan a nuestro control).
Ese enlace de invitación se “soltó”, incluso con la diligencia del personal, ya que no podemos controlar lo que harán las personas “implícitamente autorizadas” con ese enlace; por definición, ese enlace no está “restringido”, por lo que pueden reenviarlo a quien quieran. No puedo culpar a mi personal por eso, ya que si dices que es “por diseño” hay una aprobación implícita, significa que este enlace de invitación sin restricciones puede llegar a cualquier parte, por lo tanto, eventualmente lo hará. Esto es exactamente de lo que hablaban los jefes de nuestro departamento de TI, por buenas razones. Lo sabíamos, y por eso habilitamos el “must_approve_users” para que actuara como esa capa de seguridad que pensábamos que era.
Veo que hay una pregunta sobre si esto es una característica o un error. No soy un programador profesional, eso es para que lo decidas tú (soy astrofísico). Simplemente les informo de un grave “problema” que nos causó, esperando que pueda ser abordado para que podamos seguir utilizando esta maravillosa plataforma.
Estoy totalmente a favor de la opción 3, al igual que nuestro centro de investigación y el personal de mi foro. Hasta nuevo aviso, se ha instruido al personal a no utilizar la invitación sin restricciones. Lo que añade una carga adicional, ya que ahora tienen que añadir todas las direcciones de correo electrónico individuales de las personas que queremos invitar (y en una conferencia, eso son más de cientos de participantes…). Hacerlo en cada reunión, evento, etc… añadirá una alta viscosidad a nuestro crecimiento, y puedo prever que algún miembro del personal se vaya debido a la carga de trabajo añadida (la mayoría son voluntarios, y todos están sobrecargados con sus otras tareas).
¿Es seguro asumir que si la opción 3 sigue adelante, habrá alguna opción para igualar el comportamiento existente?
El sitio de capacitación que preparamos habría sido mucho más difícil de ejecutar sin la capacidad de omitir las aprobaciones para los grupos que fueron invitados en masa.
No olvide que las invitaciones masivas también son una opción aquí, si su evento genera un csv de asistentes puede usarlo para invitar a todos directamente.
Si no es así, también puede compartir una url a un formulario web para poblar un CSV y validar usuarios allí antes de enviar la invitación masiva.
Desafortunadamente, nuestros eventos típicos no nos dan acceso a eso. Esas listas de contactos son tratadas como PII (Información de Identificación Personal) por la organización anfitriona que organiza la conferencia/reunión. Incluso si tuviéramos acceso, simplemente no tenemos la capacidad para usar esa función. Tendríamos que ponernos en contacto con un POC, que siempre está sobrecargado de trabajo (incluso si se nos permite tener acceso a la información), por lo que, de nuevo, alta viscosidad, para cuando obtengamos los enlaces de invitación, el evento habrá terminado, se habrá perdido el impulso (por parte de nuestro personal y por parte de nuestros posibles invitados).
Tomado nota. Podría ser una solución alternativa. Pero eso supone una carga de trabajo adicional para nuestro personal, que no tiene mucho ancho de banda para procesar ese paso extra. Por lo tanto, no es ideal.
Lamento que esto te haya causado problemas a ti y a tu comunidad.
De ahora en adelante, ya sabes cómo funciona, ¡así que puedes asegurarte de que tú y los demás administradores y moderadores usarán el sistema de invitaciones con prudencia!
La pregunta sobre funcionalidad frente a error se refiere a la priorización: ¡intentamos corregir los errores rápidamente, especialmente si son errores de seguridad! Pero en este caso, la funcionalidad es la misma que ha sido durante años y está diseñada de esta manera. Creo que deberíamos cambiarlo, pero no es algo para dejar todo y arreglarlo ahora.
Le daremos tiempo a otros para que opinen, así podremos decidir la dirección que queremos tomar.
Puede ser un cambio mucho más complejo dependiendo de cómo el guardián participe en los diferentes elementos de este proceso, pero otra opción, que también dependería de 3, es:
Añade una propiedad booleana a las propias invitaciones para omitir la aprobación del usuario. Esta propiedad estaría desactivada por defecto y solo se mostraría en la interfaz de usuario de creación de invitaciones cuando must_approve_users esté habilitado.
Editar: De hecho, al mirar de nuevo el código al que David hizo referencia, supongo que el guardián no participa en absoluto en la decisión de si un usuario invitado necesita ser aprobado. Parece que esa parte sería un reemplazo directo de invite.invited_by.staff? con algo como invite.bypass_approval?
Entiendo completamente tus limitaciones de priorización. Supongo que nuestra instancia se encuentra en una situación poco común, ya que todas las instancias de Discourse que conozco pertenecen a organizaciones que no tienen las estrictas políticas de seguridad que debemos cumplir. Por ejemplo, la invitación exclusiva fue una restricción impuesta por nuestra organización; nuestra instancia no podría existir con auto-registro. Con un auto-registro, sería más fácil, no necesitaríamos usar las invitaciones sin restricciones que pueden “soltarse”.
