Permisos granulares basados en grupos para usuarios anónimos y registrados

Noticias y Eventos Anuncios
1

Históricamente ha existido un pseudogrupo confuso llamado @everyone dentro de nuestra base de código, el cual se puede utilizar para:

  • Configuraciones del sitio de tipo group_list
  • Permisos de categorías
  • Grupos de etiquetas

En algunos casos, las personas interpretan @everyone como “todos los usuarios anónimos y todos los usuarios con sesión iniciada”, mientras que otros lo interpretan como solo “todos los usuarios con sesión iniciada”. La realidad para las configuraciones del sitio es que, en la mayoría de los casos, solo significa “todos los usuarios con sesión iniciada”.

Aún más confuso es el hecho de que este grupo @everyone pueda utilizarse en configuraciones del sitio donde no tiene sentido que “todos los anónimos y usuarios con sesión iniciada” tengan acceso a la función, como pm_tags_allowed_for_groups.

Esto también genera confusión desde la perspectiva de la gestión de flags de funcionalidades y la experiencia del desarrollador, ya que para algunos cambios futuros u otras configuraciones podríamos querer habilitarlas realmente para “todos los anónimos y usuarios con sesión iniciada”.

Solución

Estamos introduciendo dos pseudogrupos automáticos separados:

  • anonymous_users (ID 4) — Representa a los usuarios anónimos que visitan tu sitio sin cuenta
  • logged_in_users (ID 5) — Representa a todos los usuarios con sesión iniciada en tu sitio, con un efecto similar al del grupo automático trust_level_0, pero más específico

Estos ya han sido introducidos, pero solo entrarán en vigor cuando se habilite el cambio futuro granular_anonymous_and_logged_in_groups_permissions en tu sitio.

Cuando se habilite el cambio futuro, cualquier configuración que tenga everyone como grupo seleccionado se traducirá automáticamente al ID logged_in_users, por lo que ningún dato en la tabla de configuraciones del sitio cambiará al activar el cambio futuro. Cuando el cambio futuro se vuelva permanente, realizaremos una migración de datos para todas las configuraciones de grupos para aplicar este cambio.

Además, hemos marcado anonymous_users como un disallowed_group para varias configuraciones del sitio donde no tiene sentido, por ejemplo personal_message_enabled_groups.

image
image1217×205 51.6 KB

Los conflictos con nombres de grupos existentes se manejan automáticamente, renombrando los grupos existentes y actualizando las menciones de grupos en las publicaciones.

¿Qué pasa con los permisos de etiquetas y categorías?

Estos permisos permanecerán sin cambios, ya que su concepto de “todos” es diferente en varios aspectos y no depende del grupo automático subyacente.

8 Me gusta
Db:seed_fu fails on 002_groups.rb during upgrade: Validation failed: Name has already been taken
3

Espera… ¿qué? :flushed_face: ¿Eso significa que todas las categorías que ahora son públicas (para todos) se cambiarán a cerradas, requiriendo inicio de sesión, cuando eso esté habilitado?

4

No, porque:

Esto solo afecta a los ajustes del sitio de tipo lista de grupos que actualmente permiten seleccionar “todos” de la siguiente manera:

image
image909×273 54 KB

1 me gusta
5

¿Puede alguien ayudarme a entender cómo debo ajustar los componentes de mi tema?

Intenté usar el componente copy-post como ejemplo, ya que recuerdo que también utiliza una configuración de grupo que otorga acceso a la función. Y que hubo un problema porque el pseudogrupo «todos» requería una verificación separada, al igual que en mi componente, ya que comparar los IDs de los grupos a los que pertenece el usuario no ayuda; esos IDs deben verificarse por separado. Por eso esperaba un cambio reciente allí, porque, según mi entendimiento, los nuevos grupos también son pseudogrupos y el ID debería verificarse por separado. ¿Estoy pasando por alto algo que explique por qué esto no es necesario aquí?

Mi componente favorite filters tiene dos configuraciones de grupo: una que permite a los grupos guardar sus propios filtros y otra que ofrece filtros estándar.
Por defecto, solo los miembros del grupo trust_level_0 pueden usar filtros personalizados, ya que solo los usuarios registrados pueden tener datos almacenados en un campo de usuario personalizado. Por lo tanto, en este caso tendría sentido que no permitiera anonymous_users como selección. ¿Cómo lo hago en un componente de tema? ¿Ya existe algún ejemplo para esto?

La configuración predeterminada para los filtros predeterminados es «todos», porque considero útil que incluso los usuarios no registrados puedan ver y usar los filtros predeterminados. El problema es que everyone cambia a «logged_in_users» incluso aunque lo haya seleccionado específicamente. ¿Necesito crear una migración personalizada para que los administradores que actualmente usan everyone sigan teniendo filtros para usuarios no registrados en el futuro? ¿Cuándo debe llevarse a cabo esta migración? ¿O debe cambiar cada administrador esto individualmente después de que se haya ejecutado la migración?

¿Es realmente innecesario todo esto de lo que me estoy preocupando? Si se necesitan ajustes, menos de cuatro semanas parece un plazo bastante corto, considerando la cantidad de componentes mantenidos por la comunidad que podrían verse afectados.
Además de «copy-post», también revisé el componente unanswered filter, pero tampoco encontré ningún cambio allí. Siento que estoy pasando por alto algo importante. Después de todo, el cambio se ha habilitado por defecto desde hace casi una semana. Por eso asumo que los componentes oficiales ya habrían sido actualizados si fueran necesarios ajustes.

1 me gusta
6

Se fusionaron 3 publicaciones en un tema existente: Modernización del tema Foundation

7

Al observar estos componentes, currentUser?.groups no es confiable de todos modos, ya que solo incluye grupos visibles para el usuario, y los grupos en los que está y que afectan los permisos podrían no estar serializados aquí:

En el núcleo y los plugins, sorteamos esto haciendo cosas como las siguientes en el serializador de usuario actual:

Pero, obviamente, esto no está disponible para los componentes de temas o los temas y sus configuraciones.

Hmm, no estoy seguro, tendré que pensarlo. Si realmente querías decir everyone, entonces tendría que cambiar tanto a logged_in_users como a anonymous_users. Este fue el principal problema con everyone, como se mencionó en la publicación original: algunas personas lo interpretaron como solo usuarios con sesión iniciada, otros como usuarios con sesión iniciada más anónimos, y dependía mucho de la situación.

Elegí la interpretación de «solo usuarios con sesión iniciada» porque era más segura desde el punto de vista de la seguridad.

No, simplemente no pensé en los componentes de temas o los temas y sus configuraciones, ni en cómo se verían afectados por este cambio; estaba enfocado principalmente en la configuración del sitio. Cosas como esta serán especialmente difíciles de encontrar, ya que ni siquiera están usando la constante AUTO_GROUPS:

image

De todos modos, pensaré en algunas soluciones para estos problemas y no moveré este cambio a Stable hasta que los resuelva.

2 Me gusta
9

Actualización rápida: se me ha ocurrido una idea para manejar esto y estamos teniendo algunas discusiones internas al respecto. Espero que no tome demasiado tiempo :crossed_fingers:

1 me gusta