Login de membros do serviço
Última atualização: 3 de julho de 2026
Imagine que você administra o site de uma loja de roupas. Há momentos em que você quer que os clientes se cadastrem por conta própria e que apenas membros possam escrever avaliações ou receber benefícios por nível. Para isso, você precisa de um "sistema de membros em que o cliente se cadastra e faz login sozinho". O recurso do Space que conecta esse sistema de membros ao seu site é o ServiceLogin (a configuração de login pela qual os clientes se cadastram diretamente no seu serviço).
Quando você ativa o ServiceLogin, qualquer cliente pode se cadastrar diretamente com uma conta social como o Google. Cada cliente cadastrado se torna um ServiceUser (um membro cadastrado no seu serviço). O processo de login e a manutenção do estado de sessão são tratados pela WEEGLOO, então você não precisa guardar senhas por conta própria nem construir o login social do zero.
Nesta página, você primeiro entende o que é o ServiceLogin e como ele se diferencia das contas da equipe de operação. Em seguida, você mesmo ativa e configura o ServiceLogin no Space da loja de roupas.
Membros são diferentes da equipe de operação
Na WEEGLOO existem dois tipos de pessoas que fazem login. É fácil confundir, então vamos traçar a fronteira primeiro.
- A equipe/operação são as pessoas que cadastram produtos e administram o site. Elas não se cadastram pelo ServiceLogin como um cliente, mas entram com uma conta WEEGLOO ao se tornarem membros deste Space (por meio do convite e da atribuição de papel feitos por quem já está dentro). As permissões da equipe de operação são tratadas em Papéis e permissões.
- O ServiceUser é o cliente/membro que usa esse site. É a pessoa que se cadastrou diretamente com uma conta social no site da loja de roupas que você administra. É um login completamente separado do da equipe de operação.
Em poucas palavras, a equipe de operação é "quem cuida da loja" e o ServiceUser é "o cliente que visita a loja". O ServiceLogin é o trabalho de criar a porta de entrada por onde esses clientes passam.
As três coisas que trabalham juntas
O sistema de membros funciona com três coisas engrenadas entre si.
- ServiceLogin: é a própria configuração de login. Aqui você define coisas como qual login social usar e qual permissão dar por padrão ao membro cadastrado.
- ServiceUserRole: é o conjunto de permissões a ser concedido ao membro. Define o que o membro pode ver e o que pode escrever.
- ServiceUser: é cada membro cadastrado, um a um. Um é criado a cada vez que um cliente se cadastra.
Esta página se concentra na configuração do ServiceLogin, que abre a porta de entrada. O ServiceUserRole, que define o que o membro realmente pode ver e escrever (permissões), é tratado separadamente em Papéis e permissões de membros. O Default Role que você escolhe na configuração abaixo é justamente o papel que você cria naquela página.
Ativar o ServiceLogin
Vamos ativar o login de membros no Space da loja de roupas.
A configuração de login de membros existe apenas uma por Space. Você não cria várias novas; mantém essa única ativada e a ajusta conforme a necessidade.
O ServiceLogin começa desativado. Ao abrir a tela de configuração, aparece o aviso "ServiceLogin is disabled" junto com o botão Activate. No aviso está escrito: "Activate ServiceLogin to enable social login (Google, etc.) on your site. Weegloo handles OAuth and sessions for you".
- No menu à esquerda, expanda Serviços e clique em ServiceLogin.
- Na tela Informações básicas, clique no botão Activate.
Ao clicar em Activate, o formulário de configuração se abre. Nesse formulário, é preciso ativar um ou mais logins sociais e clicar em Guardar para que o login de membros realmente funcione.
Preencher o formulário de configuração
O formulário de configuração se divide em informações básicas e configuração de login social. Primeiro, preencha as informações básicas.
| Item | O que preencher |
|---|---|
| Service name | É o nome do serviço que aparece ao cliente no momento do login. No caso de uma loja de roupas, escreva o nome da loja. |
| Contact email | É o contato a ser mostrado ao cliente quando ocorrer um problema no login (por exemplo, quando o número de vagas para cadastro estiver esgotado). |
| Callback URI | É o endereço do seu site para onde o cliente retorna depois de concluir o login. |
| Default Role | É o conjunto de permissões dado automaticamente a um cliente recém-cadastrado. Ao clicar em Manage Roles ao lado, você vai para a tela de criação de permissões. |
- Em Service name, digite o nome que aparecerá ao cliente. No caso de uma loja de roupas, escreva o nome da loja, como
Guarda-Roupa Aconchegante. - Em Contact email, digite o endereço que receberá as dúvidas. Por exemplo:
help@pogeun-otjang.com. - Em Callback URI, digite o endereço do seu site para onde o cliente retornará após o login. Por exemplo:
https://pogeun-otjang.com/auth/callback. - Em Default Role, escolha a permissão a conceder ao novo membro. Se ainda não houver nenhuma permissão criada, crie uma primeiro em Manage Roles ao lado e volte.
O que escolher em Default Role e qual permissão dar ao membro é tratado em Papéis e permissões de membros.
Se a equipe de operação quiser verificar uma vez antes de aceitar o cadastro, você pode deixar ativada a opção Exigir aprovação do admin para novos registos. Com essa opção ativada, o cliente recém-cadastrado não consegue fazer login de imediato e aguarda até que a equipe de operação aprove. Membros que já estão cadastrados não são afetados.
- Para que qualquer pessoa faça login imediatamente após o cadastro, deixe Exigir aprovação do admin para novos registos desativada. Se quiser verificar cada cadastro individualmente, deixe ativada.
Ativar o login social
Com qual conta o cliente vai se cadastrar é definido em Login Providers. Você pode ativar Google, GitHub, Facebook, GitLab, LINE, Kakao e Naver, cada um separadamente.
O login social é o trabalho de ligar dois lugares. Você registra o seu site do lado do provedor (no caso do Google, por exemplo, o Google Cloud Console) e insere na WEEGLOO os valores recebidos de lá. Ao ativar o Google, a tela guia você por essas duas etapas exatamente.
- Ative o Google. Aparece o guia de duas etapas.
- Copie a Authorized redirect URI que aparece em Step 1 e registre-a no cliente OAuth do Google Cloud Console. Esse endereço informa ao Google para onde devolver o resultado do login.
- Insira os valores emitidos pelo Google Cloud Console nos campos Client ID e Client Secret do Step 2.
- Se quiser usar outros logins sociais, ative o GitHub ou o Facebook do mesmo modo, insira os valores e clique em Guardar.
Quando o login social que você ativou aparecer na lista como ativado e você concluir o Guardar, o cliente poderá fazer login com aquela conta.
O que muda de um provedor para outro: escopos e e-mail
O procedimento de conexão é o mesmo descrito acima para qualquer provedor. O nome do campo em que você registra o endereço de redirecionamento varia um pouco de um provedor para outro (Authorized redirect URI, Callback URL, Redirect URI, entre outros). Mesmo com nomes diferentes, o valor é o mesmo: cole o endereço mostrado no Step 1 do guia exibido ao ativar o provedor, exatamente como aparece.
Os escopos da tabela abaixo (o alcance das informações solicitadas ao cliente no momento do login) são os valores que a WEEGLOO solicita ao provedor no momento do login. No Google, no GitHub e no Facebook não há nada para especificar antecipadamente no console; basta o cliente consentir ao fazer login. Nos demais provedores há itens que precisam ser ativados com antecedência no console, então confira na tabela.
A WEEGLOO distingue os membros cadastrados pelo e-mail. Por isso, se o provedor não repassar o e-mail, não é possível fazer login com aquela conta. Para o procedimento detalhado de criação do app OAuth, siga a documentação oficial de cada provedor.
| Provedor | Escopos que a WEEGLOO solicita | O que ativar antes no console do provedor | Documentação oficial |
|---|---|---|---|
email, profile | Nada | Documentação do Google | |
| GitHub | read:user, user:email | Nada | Documentação do GitHub |
email, public_profile | Nada | Documentação do Facebook | |
| GitLab | read_user | Marque read_user nos escopos ao criar o app | Documentação do GitLab |
| Kakao | profile_nickname, profile_image, account_email | Após converter o app em Biz App, é necessária a aprovação de uso do item de consentimento de e-mail | Documentação do Kakao |
| Naver | email, profile, nickname | É preciso incluir o endereço de e-mail nas informações fornecidas ao registrar o app | Documentação do Naver |
| LINE | profile, email | É preciso solicitar a permissão de e-mail no canal e obter a aprovação | Documentação do LINE |
Ver os membros cadastrados
Quando um cliente se cadastra, você pode conferir esse membro em Serviços > ServiceLogin > Users. Aqui você vê e gerencia a lista de membros cadastrados.
Se você tiver deixado ativada a opção Exigir aprovação do admin para novos registos anteriormente, o membro recém-cadastrado aguarda aprovação nesta tela. Quando você ativa o membro, ele pode fazer login a partir daí.
Login de membros quando há vários sites
Uma mesma pessoa às vezes administra vários serviços diferentes. Imagine que, além de administrar a loja de roupas Guarda-Roupa Aconchegante, você também cuida do site de uma padaria de bairro, um ramo completamente diferente. Os dois sites têm clientes diferentes e tratam de conteúdos diferentes. Não há motivo para que um cliente cadastrado na loja de roupas seja membro da padaria.
O login de membros existe um por Space. Por isso, sites tão diferentes assim criam cada um o seu Space e configuram o login de membros separadamente em cada Space. A lista de membros também se divide por Space, de modo que os membros da loja de roupas e os da padaria são gerenciados como membros diferentes.
O login de membros de um Space é usado no site administrado por esse Space. Não é um modo de acoplar um único login de membros a vários sites para passar por todos de uma vez. Se houver telas que você quer que o membro use juntas com um único login, reúna essas telas em um só site.
Próximos passos
- Papéis e permissões de membros: cria o ServiceUserRole que define o que o membro cadastrado pode ver e escrever, e o conecta ao Default Role escolhido acima.
- Referência da API: para conectar o login do membro cadastrado ao código do seu site, é preciso o SDK cliente oficial e especificações técnicas como o formato das requisições. As especificações para tratar diretamente em programa o conteúdo que o membro vê e usa também são tratadas aqui.