Permissões granulares baseadas em grupos para usuários anônimos e logados

[martin (Martin Brennan)]

Houve um pseudogrupo historicamente confuso chamado @everyone em nossa base de código, que pode ser usado para:

• Configurações do site do tipo group_list
• Permissões de categoria
• Grupos de tags

Em alguns casos, as pessoas interpretam @everyone como “todos os usuários anônimos e todos os usuários logados”, enquanto outras entendem que significa apenas “todos os usuários logados”. Na realidade, para configurações do site, na maioria dos casos, isso significa apenas “todos os usuários logados”.

Ainda mais confuso é o fato de que esse grupo @everyone pode ser usado em configurações do site onde não faz sentido que “todos os usuários anônimos e logados” tenham acesso ao recurso, como em pm_tags_allowed_for_groups.

Isso também gera confusão do ponto de vista de sinalização de recursos e experiência do desenvolvedor, pois para algumas mudanças futuras ou outras configurações, podemos realmente querer habilitá-las para “todos os usuários anônimos e logados”.

Solução

Estamos introduzindo dois pseudogrupos automáticos separados:

• anonymous_users (ID 4) — Representa usuários anônimos que visitam seu site sem conta
• logged_in_users (ID 5) — Representa todos os usuários logados em seu site, com efeito semelhante ao grupo automático trust_level_0, mas mais específico

Esses grupos já foram introduzidos, mas só entrarão em vigor quando a mudança futura granular_anonymous_and_logged_in_groups_permissions for habilitada em seu site.

Quando a mudança futura for habilitada, qualquer configuração com everyone como grupo selecionado será automaticamente traduzida para o ID logged_in_users, de modo que nenhum dado na tabela de configurações do site será alterado ao alternar a mudança futura. Quando a mudança futura se tornar permanente, realizaremos uma migração de dados para todas as configurações de grupo para aplicar essa alteração.

Além disso, marcamos anonymous_users como um disallowed_group para várias configurações do site onde não faz sentido, como personal_message_enabled_groups.

Conflitos com nomes de grupos existentes são tratados automaticamente, renomeando os grupos existentes e atualizando as menções de grupo nos posts.

E quanto às permissões de tags e categorias?

Essas permissões permanecerão inalteradas, pois o conceito de “todos” nelas difere de algumas maneiras e não depende do grupo automático subjacente.

[Jagster (Jakke Flemming)]

Espera… o quê Isso significa que todas as categorias que agora são públicas (todos) serão alteradas para categorias fechadas que exigem login, quando isso for ativado?

@martin

qualquer configuração com todos como grupo selecionado será automaticamente traduzida para o ID logged_in_users.

[martin (Martin Brennan)]

@Jagster

Espera… o que Isso significa que todas as categorias que estão agora públicas (todos)

Não, porque:

@martin

E quanto às permissões de tags e categorias?

Essas permissões permanecerão inalteradas, pois o conceito de “todos” é diferente em alguns aspectos e não depende do grupo automático subjacente.

Isso afeta apenas as configurações do site do tipo lista de grupos que atualmente permitem selecionar “todos” da seguinte forma:

[Moin]

Alguém pode me ajudar a entender como preciso ajustar meus componentes de tema?

Tentei usar o componente copy-post como exemplo, pois lembro que ele também usa uma configuração de grupo que concede acesso ao recurso. E que houve um problema porque o pseudogrupo “everyone” exigia uma verificação separada, assim como no meu componente, pois comparar os IDs dos grupos aos quais o usuário pertence não ajuda — esses IDs precisam ser verificados separadamente. Por isso, eu esperava uma mudança recente ali, pois, conforme entendo, os novos grupos também são pseudogrupos e o ID precisaria ser verificado separadamente. Estou perdendo algo que explique por que isso não é necessário aqui?

Meu componente favorite filters possui duas configurações de grupo: uma que permite que grupos salvem seus próprios filtros e outra que oferece filtros padrão.
Por padrão, apenas membros do grupo trust_level_0 podem usar filtros personalizados, pois apenas usuários registrados podem ter dados armazenados em um campo personalizado de usuário. Então, aqui faria sentido se eu não permitisse anonymous_users como uma seleção. Como faço isso em um componente de tema? Já existe algum exemplo para isso?

A configuração padrão para os filtros padrão é “everyone”, pois acho útil que até mesmo usuários não registrados possam ver e usar os filtros padrão. O problema é que everyone muda para logged_in_users, mesmo que eu o tenha selecionado especificamente. Preciso criar uma migração personalizada para isso, para que os administradores que atualmente usam everyone continuem tendo filtros para usuários não registrados no futuro? Quando essa migração precisa ocorrer? Ou cada administrador precisa alterar isso individualmente após você ter executado a migração?

Tudo isso que estou me preocupando é realmente desnecessário? Se forem necessários ajustes, menos de quatro semanas parece um prazo bastante curto, dado o número de componentes mantidos pela comunidade que poderiam ser potencialmente afetados.
Além do “copy-post”, também examinei o componente unanswered filter, mas não encontrei nenhuma mudança ali também. Sinto como se estivesse ignorando algo importante. Afinal, a mudança foi ativada por padrão há quase uma semana. Por isso, assumo que os componentes oficiais já teriam sido atualizados se ajustes fossem necessários.

[martin (Martin Brennan)]

Ao analisar esses componentes, currentUser?.groups não é confiável de qualquer forma, pois inclui apenas os grupos visíveis para o usuário, e os grupos nos quais ele está e que afetam as permissões podem não ser serializados aqui:

app/serializers/current_user_serializer.rb

No núcleo e nos plugins, contornamos isso fazendo coisas como esta no serializador do usuário atual:

app/serializers/current_user_serializer.rb

Mas, obviamente, isso não está disponível para componentes de temas e seus ajustes.

@Moin

O problema é que everyone muda para ‘logged_in_users’ mesmo tendo selecionado especificamente essa opção. Preciso criar uma migração personalizada para isso, de modo que os administradores que atualmente usam everyone continuem tendo filtros para usuários não registrados no futuro? Quando essa migração precisa ocorrer? Ou cada administrador precisa alterar isso individualmente após você executar a migração?

Hmm, não tenho certeza, terei que pensar sobre isso. Se você realmente quis dizer everyone, então seria necessário alterar para logged_in_users E anonymous_users. Esse foi o principal problema com everyone, conforme mencionado no OP — algumas pessoas interpretaram como apenas usuários logados, outras como logados + anônimos, e isso dependia muito da situação.

Escolhi a interpretação de „apenas usuários logados“ porque era mais segura do ponto de vista de segurança.

@Moin

Sinto que estou deixando passar algo importante. Afinal, a alteração foi ativada por padrão há quase uma semana. Por isso, assumo que os componentes oficiais já teriam sido atualizados se ajustes fossem necessários.

Não, simplesmente não pensei em componentes de temas e seus ajustes e como seriam impactados por essa mudança. Eu estava focado principalmente nas configurações do site. Coisas como essa serão especialmente difíceis de encontrar, pois nem mesmo estão usando a constante AUTO_GROUPS:

De qualquer forma, vou pensar em algumas soluções para esses problemas e não avançarei essa mudança para a versão Stable até resolvê-los.