Tivemos um sério problema de segurança com o sistema de convites. Acho que é facilmente reproduzível. Nosso site é apenas por convite. Além disso, marcamos “deve aprovar usuários” nas configurações.
Um de nossos funcionários emitiu um convite com uso máximo maior que 1, portanto, não restrito a um e-mail específico (exemplo abaixo).
Esse link de convite circulou e as pessoas puderam se registrar com ele. No entanto, esperávamos que, quando “deve aprovar usuários” estivesse marcado nas configurações, a equipe tivesse que aprovar qualquer pessoa que usasse esses convites “sem restrição de e-mail”. Em vez disso, todos foram aceitos automaticamente, quem quer que tivesse aquele link. Portanto, o link pode ser usado por qualquer pessoa e não podemos verificar quem entra com ele. Precisamos ser capazes de fazer uma “verificação de antecedentes”, usando a combinação de e-mail, nome e outros campos que adicionamos, que são campos obrigatórios que pedimos para aprovar (depois que verificamos).
Isso criou um sério problema, pois alguém de uma organização estrangeira estritamente proibida obteve esse link e se registrou. Tive que excluir essa conta imediatamente. Essa é uma falha séria para nós.
Portanto, acho a opção “deve aprovar usuários” perigosamente enganosa. Atualmente, essa opção é inútil se estivermos em uma instância apenas por convite.
Existe alguma maneira de a equipe poder aprovar alguém que usa o link de convite que não foi restrito por e-mail? Isso pareceria uma maneira lógica de ter a opção “deve aprovar usuários” ativada quando o site é apenas por convite.
Consigo reproduzir o problema, quando um convite em massa é gerado, os usuários que se inscrevem com esse link ficam automaticamente imunes à configuração de aprovação de usuários obrigatória.
A coisa fundamental aqui é que um membro da equipe emitiu o convite. O Discourse trata isso como uma aprovação implícita dos usuários que utilizam o convite.
Se um não membro da equipe gerou o convite, o usuário que o resgatou seria adicionado à fila para aprovação da equipe.
então, se uma conta de usuário não-membro for usada para criar um convite, as inscrições por meio desse convite seriam colocadas na fila de revisão? Se for esse o caso, é um comportamento totalmente aceitável e @Wall-E você poderia usar uma conta regular fictícia para gerar o convite como uma solução alternativa.
Acho que deveria haver pelo menos um aviso para os usuários da equipe, e seria fantástico se eles pudessem escolher como os novos membros serão tratados. Usar um segundo usuário, “normal”, seria uma solução alternativa feia.
Ao ler este tópico e os tópicos anteriores, posso ver que o funcionamento atual é “por design”, mas não reflete as novas alterações no sistema de convites. Tornou-se muito mais fácil criar links de convite que podem ser usados por pessoas desconhecidas. Os links de convite agora também podem ser criados perigosamente por funcionários que adicionam convidados a grupos que podem ter acesso a categorias seguras no site.
@Wall-E Tenho curiosidade em entender como seus links de convite estão caindo nas mãos de pessoas que não deveriam ter acesso ao seu site. Presumivelmente, a equipe do seu site saberá ter cuidado para não criar links de convite que possam ser usados por qualquer pessoa e compartilhá-los publicamente ou em configurações onde as pessoas erradas poderão usá-los. Em certa medida, o problema que você está enfrentando é um problema de treinamento da equipe. Sinta-se à vontade para me enviar uma mensagem privada com sua resposta se ela contiver detalhes sensíveis.
Se houver links de convite existentes atualmente que estejam de alguma forma comprometidos, você pode excluí-los e criar novos e compartilhá-los com mais cuidado no futuro. Como administrador, você também pode sempre verificar a página de convites do usuário para ver quem resgatou seus convites. Se você tiver funcionários em quem não confia, pode diminuir seus privilégios para TL4, que possui privilégios de moderador.
Vejo três possíveis cursos de ação:
Não fazer nada. O sistema de convites está funcionando como projetado, a equipe só precisa ter cuidado com seus links de convite. Se seguirmos por esse caminho, sugiro que alteremos a descrição da configuração de administrador must approve users para deixar cristalino que os links de convite criados por administradores ignoram essa configuração.
A equipe deve aprovar todas as novas contas de usuário antes que elas possam acessar o site. Nota: convites criados pela equipe ignoram essa configuração e não requerem aprovação.
Fazer (1), mas também adicionar uma etapa extra de aviso “tem certeza?” quando os administradores criarem um link de convite que possa ser usado para obter acesso imediato ao site. Apenas em sites com aprovação necessária.
Alterar o comportamento para que os links de convite criados por administradores respeitem a configuração de aprovação necessária, assim como os convites de não administradores.
Concordo com o OP que o comportamento atual é enganoso e tem o potencial de levar a problemas em sites quando a aprovação é necessária. Sites com essa configuração ativada são extra cautelosos e precisam desse nível extra de paranoia de controle sobre quem pode obter acesso.
Minha recomendação, portanto, seria escolhermos a porta número três - fazer com que todos os links de convite funcionem da mesma maneira e respeitem a configuração must approve users.
Não acho que isso seja um bug, no entanto. Está funcionando como projetado. Reclassificando como solicitação de recurso.
Também sou fortemente a favor da opção 3. Estou construindo uma comunidade onde as pessoas podem refletir mais profundamente sobre emoções e acho que adicionar esse nível extra de restrição aos links de convite anônimos (porque eles não estão vinculados a um e-mail ou identidade) pode me deixar mais tranquilo de que apenas as pessoas que eu quero que participem o farão.
Suponho que eu poderia garantir o uso do e-mail de convite em vez do link de convite anônimo, mas o link facilita muito o compartilhamento no WhatsApp ou em outras plataformas de comunicação.
Portanto, também sou a favor de fazer com que os links de convite anônimos respeitem a configuração de aprovação de usuários.
Além disso, acho que se a #3 acontecer, o sistema de convites poderá funcionar quase como um sistema de inscrição para fóruns apenas por convite. No momento, não tenho certeza de como as pessoas poderiam se candidatar a membro sem ter um Google Forms separado ou algo assim. Isso poderia simplificar as coisas, onde campos de usuário personalizados poderiam ser o formulário de inscrição — que é o que acho que @Wall-E está tentando fazer.
Isso não é sobre o que meu tópico trata. Estou falando sobre os must_approve_users não terem efeito em uma instância apenas por convite. Ativá-lo deveria ter um efeito diferente de desativá-lo. Se não, então deve ser documentado que esse comportamento não se aplica a instâncias apenas por convite. Se eu perdi isso na documentação, então é de fato responsabilidade de nossa equipe. Mas se não for, então esse recurso é enganoso e deve ser corrigido, ou pelo menos documentado), pois enganou toda a nossa equipe.
Com certeza. Eu poderia ter perdido na documentação, se estivesse documentado, então seria minha responsabilidade ter enganado minha equipe, e um aviso não faria mal, porque as pessoas/equipe podem esquecer.
Vou citar as autoridades que podem nos derrubar devido a esse aspecto, que é considerado um problema de segurança em nossa organização: “Se este sistema pode permitir que alguém de uma organização não autorizada entre, você tem que assumir que eventualmente o fará, independentemente da sua diligência”. Foi exatamente o que aconteceu. Essa “funcionalidade” (eu diria, uma não-funcionalidade, já que o “must_approve_user” simplesmente não tem efeito no caso de convite apenas) foi ativada, emitimos o convite irrestrito para as pessoas exatas que queríamos convidar, e obviamente, uma dessas pessoas compartilhou esse link de convite irrestrito com outra organização.
Com isso, também estou respondendo a @tobiaseigen
Temos reuniões, conferências, com às vezes centenas de pessoas de organizações autorizadas que podem participar do nosso fórum. Mas algumas delas são às vezes de outras organizações que não estão autorizadas a participar do nosso fórum (devido a políticas gerais que não estão sob nosso controle).
Esse link de convite “escapou”, mesmo com a diligência da equipe, pois não podemos controlar o que as pessoas “implicitamente autorizadas” com esse link farão; por definição, esse link é “irrestrito”, então elas podem encaminhá-lo para quem quiserem. Não posso culpar minha equipe por isso, pois se você diz que é “por design” há uma aprovação implícita, isso significa que esse link de convite irrestrito pode chegar a qualquer lugar, portanto, eventualmente chegará. É exatamente sobre isso que os chefes do nosso departamento de TI estavam falando, por bons motivos. Sabíamos disso, e por isso ativamos o “must_approve_users” para atuar como essa camada de segurança que pensávamos que era.
Vejo que há uma questão sobre se isso é uma funcionalidade ou um bug. Não sou um programador profissional, isso cabe a vocês decidirem (sou astrofísico). Estou meramente relatando um sério “problema” que isso nos causou, esperando que possa ser resolvido para que possamos continuar usando esta maravilhosa plataforma.
Sou totalmente a favor da opção 3, assim como nosso centro de pesquisa e a equipe do meu fórum. Até novo aviso, a equipe está instruída a não usar o convite irrestrito. O que adiciona um fardo extra, pois agora eles precisam adicionar todos os endereços de e-mail individuais das pessoas que queremos convidar (e em uma conferência, isso são mais de centenas de participantes…). Fazer isso em cada reunião, evento, etc… adicionará alta viscosidade ao nosso crescimento, e posso prever que alguns membros da equipe sairão devido à carga de trabalho adicional (a maioria deles são voluntários e todos sobrecarregados com suas outras funções).
É seguro assumir que, se a opção 3 for adiante, haverá alguma opção para corresponder ao comportamento existente?
O site de treinamento que montamos teria sido muito mais difícil de executar sem a capacidade de ignorar aprovações para os grupos que foram convidados em massa.
Não se esqueça que convites em massa também são uma opção aqui, se o seu evento gerar um CSV de participantes você pode usá-lo para convidar todos diretamente.
Caso contrário, você também pode compartilhar uma URL para um formulário da web para popular um CSV e validar usuários lá antes de enviar o convite em massa.
Infelizmente, nossos eventos típicos não nos dão acesso a isso. Essas listas de contatos são tratadas como PII (Informações de Identificação Pessoal) pela organização anfitriã que realiza a conferência/reunião. Mesmo que tivéssemos acesso, simplesmente não temos largura de banda para usar esse recurso. Teríamos que entrar em contato com um POC, que está sempre sobrecarregado (mesmo que tenhamos permissão para ter acesso às informações), então, novamente, alta viscosidade, quando conseguimos os links de convite, o evento já acabou, o momentum é perdido (por nossa equipe e por nossos potenciais convidados).
Anotado. Isso poderia ser uma solução alternativa. Mas isso representa uma carga de trabalho adicional para nossa equipe, que não tem muita capacidade para processar essa etapa extra. Portanto, isso não é ideal.
Peço desculpas por isso ter causado problemas para você e sua comunidade!
Daqui para frente, agora você sabe como funciona, para que possa ter certeza de que você e outros administradores e moderadores usarão o sistema de convites com critério!
A questão funcionalidade versus bug é sobre priorização - tentamos corrigir bugs rapidamente, especialmente se forem bugs de segurança! Mas, neste caso, a funcionalidade é a mesma de anos e é assim por design. Acho que deveríamos mudar, mas não é algo para parar tudo e consertar agora.
Daremos um tempo para que outros opinem, para que possamos decidir a direção que gostaríamos de seguir.
Pode ser uma mudança muito mais complexa, dependendo de como o guardião está envolvido nos diferentes elementos deste processo, mas outra opção, que também dependeria de 3, é:
Adicione uma propriedade booleana aos próprios convites para contornar a aprovação do usuário. Esta propriedade estaria desativada por padrão e seria exposta apenas na interface do usuário de criação de convite quando must_approve_users estiver habilitado.
Editar: Na verdade, olhando novamente para o código que David referenciou, acho que o guardião não está envolvido de forma alguma na decisão de se um usuário convidado precisa ser aprovado. Parece que essa parte seria uma substituição direta de invite.invited_by.staff? por algo como invite.bypass_approval?
Eu entendo completamente suas restrições de priorização. Acho que nossa instância está em uma situação incomum, pois todas as instâncias do Discourse que conheço são de organizações que não possuem as rigorosas políticas de segurança pelas quais temos que nos ater. Por exemplo, convite- apenas foi uma restrição imposta por nossa organização, nossa instância não poderia existir com auto-registro. Com auto-registro, seria mais fácil, não precisaríamos usar os convites irrestritos que podem se tornar “soltos”.
