# Contornar SSO adicionando e-mail desconhecido ao grupo

**URL:** https://meta.discourse.org/t/bypass-sso-by-adding-unknown-email-to-group/177339
**Category:** Bug
**Created:** [Janeiro 26, 2021, 5:23pm UTC](https://meta.discourse.org/t/bypass-sso-by-adding-unknown-email-to-group/177339 "2021-01-26T17:23:19Z")
**Posts on this page:** 10
**Page:** 1

<div class="post-metadata">

### Author: ![Grayden\_Shand](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/grayden_shand/32/166586_2.png) [@Grayden\_Shand](https://meta.discourse.org/u/Grayden_Shand)
#### Post date: [Janeiro 26, 2021, 5:23pm UTC](https://meta.discourse.org/t/bypass-sso-by-adding-unknown-email-to-group/177339/1 "2021-01-26T17:23:19Z")

</div>

Suponha que um site tenha o SSO ativado.

Ao adicionar usuários em massa a um grupo usando a interface [descrita aqui](https://meta.discourse.org/t/adding-users-to-groups-by-their-email-addresses/148271/3?u=grayden_shand), se um e-mail na lista de entrada não existir no Discourse, um e-mail de convite será enviado.

[![](https://global.discourse-cdn.com/meta/original/3X/9/8/98c882c27b092d83ff8f1db047afc10d0af2727c.png) ](https://dl.dropboxusercontent.com/s/7si9yyhdh3izyne/Screen%20Shot%202021-01-26%20at%2012.04.28%20PM.png?dl=0)

Se você clicar no link, será redirecionado para uma página de criação de conta dentro do Discourse:  
[![](https://global.discourse-cdn.com/meta/original/3X/5/9/5993470d0a1b293455c6fb9894f6a77611008eef.png) ](https://dl.dropboxusercontent.com/s/gso7s7gu1bozibo/Screen%20Shot%202021-01-26%20at%2012.06.21%20PM.png?dl=0)

Ao preencher o formulário, você cria uma conta. A conta criada não possui informações de SSO.  
[![](https://global.discourse-cdn.com/meta/original/3X/8/0/80fc901653cc42daa030293feb9b53f149556713.png) ](https://dl.dropboxusercontent.com/s/uzn7wk0tg24gxk6/Screen%20Shot%202021-01-26%20at%2012.11.52%20PM.png?dl=0)

Acho que está bem claro por que isso é um problema:

- Contornar nosso sistema de autenticação SSO é muito ruim.
- Sem um aviso de que “X pessoas receberão e-mails”, acabei enviando spam para pessoas sem perceber que mensagens estavam sendo enviadas.

Comportamento esperado:

- Ao adicionar usuários em massa a um grupo, se o SSO estiver ativado, ignore qualquer e-mail que ainda não esteja no site.

---

<div class="post-metadata">

### Author: ![simon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/simon/32/339122_2.png) [@simon](https://meta.discourse.org/u/simon)
#### Post date: [Janeiro 26, 2021, 6:03pm UTC](https://meta.discourse.org/t/bypass-sso-by-adding-unknown-email-to-group/177339/2 "2021-01-26T18:03:04Z")

</div>

> [@Grayden\_Shand](#):
>
> Ao adicionar usuários em massa a um grupo usando a interface [descrita aqui](https://meta.discourse.org/t/adding-users-to-groups-by-their-email-addresses/148271/3), se um e-mail na lista de entrada não existir no Discourse, um e-mail de convite será enviado.

Obrigado por relatar isso. Consegui reproduzir o problema no meu site de desenvolvimento. Quando o SSO está habilitado, quaisquer e-mails que ainda não estejam no site devem ser ignorados se forem adicionados a um grupo. Vamos corrigir isso. Desculpe pelo transtorno causado.

---

<div class="post-metadata">

### Author: ![cvx](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/cvx/32/152146_2.png) [@cvx](https://meta.discourse.org/u/cvx)
#### Post date: [Fevereiro 3, 2021, 6:08pm UTC](https://meta.discourse.org/t/bypass-sso-by-adding-unknown-email-to-group/177339/6 "2021-02-03T18:08:31Z")

</div>

Corrigido em [PR #11950](https://github.com/discourse/discourse/pull/11950) e [PR #11951](https://github.com/discourse/discourse/pull/11951). Obrigado pelo relato! 😃

---

<div class="post-metadata">

### Author: ![cvx](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/cvx/32/152146_2.png) [@cvx](https://meta.discourse.org/u/cvx)
#### Post date: [Fevereiro 4, 2021, 6:09pm UTC](https://meta.discourse.org/t/bypass-sso-by-adding-unknown-email-to-group/177339/7 "2021-02-04T18:09:28Z")

</div>

Este tópico foi fechado automaticamente 24 horas após a última resposta. Novas respostas não são mais permitidas.

---

<div class="post-metadata">

### Author: ![tgxworld](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tgxworld/32/106117_2.png) [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [Fevereiro 26, 2021, 2:47am UTC](https://meta.discourse.org/t/bypass-sso-by-adding-unknown-email-to-group/177339/8 "2021-02-26T02:47:31Z")

</div>



---

<div class="post-metadata">

### Author: ![tgxworld](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tgxworld/32/106117_2.png) [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [Fevereiro 26, 2021, 2:48am UTC](https://meta.discourse.org/t/bypass-sso-by-adding-unknown-email-to-group/177339/9 "2021-02-26T02:48:47Z")

</div>

> [@Grayden\_Shand](#):
>
> Ao adicionar em massa a um grupo, se o SSO estiver habilitado, ignore qualquer e-mail que ainda não esteja no site.

@Grayden_Shand Na verdade, estamos atualmente considerando adicionar autenticação SSO na página de resgate de convites. Ao resgatar o convite, o usuário precisará se autenticar via SSO em vez de preencher o formulário de cadastro. Isso se encaixaria no seu caso de uso?

@sam Estou pensando no fluxo de convites e uma coisa de que não tenho certeza é se o e-mail para o qual o convite foi enviado precisa corresponder ao e-mail do SSO? Parece que poderíamos impor isso para convites baseados em e-mail, mas não para convites baseados em links. O que você acha?

---

<div class="post-metadata">

### Author: ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)
#### Post date: [Fevereiro 26, 2021, 3:41am UTC](https://meta.discourse.org/t/bypass-sso-by-adding-unknown-email-to-group/177339/10 "2021-02-26T03:41:07Z")

</div>

> [@tgxworld](#):
>
> o convite enviado precisa corresponder ao e-mail do SSO?

Sim, precisamos impor isso, especialmente para sites que exigem aprovação de conta.

Então, você pode habilitar a autenticação via Facebook, desabilitar a autenticação local e ainda assim cadastrar usuários.

No entanto, os links de convite (obviamente) têm uma exceção aqui, pois não estão associados a um e-mail.

---

<div class="post-metadata">

### Author: ![Grayden\_Shand](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/grayden_shand/32/166586_2.png) [@Grayden\_Shand](https://meta.discourse.org/u/Grayden_Shand)
#### Post date: [Fevereiro 26, 2021, 1:11pm UTC](https://meta.discourse.org/t/bypass-sso-by-adding-unknown-email-to-group/177339/11 "2021-02-26T13:11:42Z")

</div>

> [@tgxworld](#):
>
> Ao resgatar o convite, o usuário precisará autenticar-se via SSO em vez de preencher o formulário de cadastro. Isso se adequa ao seu caso de uso?

Para o nosso caso de uso, seria muito melhor poder suprimir totalmente os e-mails de convite. Para a maioria dos nossos sites (comunidades temporárias para cursos online), há uma janela limitada para cadastro (e uma taxa). Então, imagino que alguém que receba um convite para o site e, ao aparecer, veja que não pode mais se juntar, ficaria frustrado. Realmente não há nenhuma circunstância em que queiramos que alguém receba um convite para um de nossos sites.

Se você prosseguir com isso, peço que também implemente um aviso com algo como: “Você está prestes a enviar e-mails para XX pessoas que não são usuárias do seu site: [bob@example.com](mailto:bob@example.com), [alice@example.com](mailto:alice@example.com), …” Assim, poderíamos encontrar esses usuários e removê-los da lista de adição em massa.

---

<div class="post-metadata">

### Author: ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)
#### Post date: [Março 1, 2021, 1:38am UTC](https://meta.discourse.org/t/bypass-sso-by-adding-unknown-email-to-group/177339/12 "2021-03-01T01:38:33Z")

</div>

Você conseguiria usar links de convite para o seu caso de uso? Assim, ninguém receberia e-mails e você teria uma data de validade.

Ainda ofereço um modo ninja para contornar o envio de e-mails, permitindo que você adicione um grande número de endereços a uma lista de permissões, mas tenho curiosidade se o recurso de links de convite elimina a necessidade disso no seu caso.

---

<div class="post-metadata">

### Author: ![Grayden\_Shand](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/grayden_shand/32/166586_2.png) [@Grayden\_Shand](https://meta.discourse.org/u/Grayden_Shand)
#### Post date: [Março 1, 2021, 2:47pm UTC](https://meta.discourse.org/t/bypass-sso-by-adding-unknown-email-to-group/177339/13 "2021-03-01T14:47:20Z")

</div>

> [@sam](#):
>
> Você poderia usar links de convite para o seu caso de uso? Assim, ninguém receberia e-mail e você teria uma data de expiração.

Acho que não, mas talvez eu não esteja entendendo a pergunta corretamente. Deixe-me explicar como usamos o Discourse, o recurso de SSO e por que esbarrei nesse bug inicialmente.

Executamos uma plataforma de e-learning que usa um fórum Discourse temporário para cada sessão de cada workshop (curso).

Usamos SSO com um sistema de autenticação personalizado por dois motivos:

1. para que o usuário precise criar apenas um conjunto de credenciais para acessar qualquer curso em que esteja inscrito.
2. para aplicar políticas sobre quem tem permissão para entrar em cada fórum Discourse com base em dados arbitrários do nosso banco de dados. Por exemplo, no nosso endpoint de SSO do Discourse, verificamos se o usuário tem uma inscrição válida e se a data está dentro dos limites das datas de abertura e fechamento.

Encontrei esse bug acima quando quis criar um grupo em um workshop apenas para pessoas que estavam em outro (como um grupo de ex-alunos). Então, adicionei a lista completa de alunos do outro workshop ao modal de adição em massa e, sem querer, enviei convites para todos na lista que não estavam inscritos no workshop atual.

Portanto, realmente nunca usaríamos o recurso de convites no Discourse (seja por link ou por e-mail). Se quiséssemos um recurso de convite, provavelmente teríamos que construí-lo nós mesmos, pois haveria alguma lógica de negócios que gostaríamos de aplicar sobre os convites enviados. Por exemplo, se o período de inscrição no workshop estivesse encerrado, gostaríamos de exibir uma mensagem de erro no link. Ou talvez quiséssemos incluir um desconto no link.

Tudo isso para dizer que funciona se não precisarmos usá-lo, mas realmente gostaríamos de não ter que nos preocupar em enviar e-mails inadvertidamente para pessoas sem conta naquele Discourse.
