Login de membros do serviço

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 Role predefinido 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 está desativado" junto com o botão Ativar. No aviso está escrito: "Ative o ServiceLogin para permitir o início de sessão social (Google, etc.) no seu site. O Weegloo trata do OAuth e das sessões por si."

  1. No menu à esquerda, expanda Serviços e clique em ServiceLogin.
  2. Na tela Informações básicas, clique no botão Ativar.

O ServiceLogin ainda não está ativado. Aparecem o aviso "ServiceLogin está desativado" e o botão Ativar

Ao clicar em Ativar, 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.

ItemO que preencher
Nome do serviçoÉ 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.
Email de contactoÉ 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).
URL de retornoÉ o endereço do seu site para onde o cliente retorna depois de concluir o login.
Role predefinidoÉ o conjunto de permissões dado automaticamente a um cliente recém-cadastrado. Ao clicar em Gerir Roles ao lado, você vai para a tela de criação de permissões.
  1. Em Nome do serviço, digite o nome que aparecerá ao cliente. No caso de uma loja de roupas, escreva o nome da loja, como Guarda-Roupa Aconchegante.
  2. Em Email de contacto, digite o endereço que receberá as dúvidas. Por exemplo: help@pogeun-otjang.com.
  3. Em URL de retorno, digite o endereço do seu site para onde o cliente retornará após o login. Por exemplo: https://pogeun-otjang.com/auth/callback. Nesse campo você coloca um endereço web como https://.... Quando você adiciona login a um aplicativo de celular (Android e iOS), não é possível colocar aqui o endereço do aplicativo diretamente, então o modo de conexão é um pouco diferente. As etapas técnicas necessárias nesse caso são tratadas em Auth API.
  4. Em Role predefinido, escolha a permissão a conceder ao novo membro. Se ainda não houver nenhuma permissão criada, crie uma primeiro em Gerir Roles ao lado e volte.

O que escolher em Role predefinido 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.

  1. 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.

Formulário de configuração do ServiceLogin que se abre após a ativação. Aparecem o Nome do serviço, o Email de contacto, a URL de retorno, o Role predefinido e a lista de logins sociais

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.

  1. Ative o Google. Aparece o guia de duas etapas.
  2. 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.
  3. Insira os valores emitidos pelo Google Cloud Console nos campos Client ID e Client Secret do Step 2.
  4. Se quiser usar outros logins sociais, ative o GitHub ou o Facebook do mesmo modo, insira os valores e clique em Guardar.

Guia de credenciais que aparece ao ativar o Google. Aparecem a Authorized redirect URI do Step 1 e os campos de Client ID e Client Secret do Step 2

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 e no GitHub 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.

Quando o cliente faz login, a WEEGLOO também recebe o e-mail do provedor e o guarda no membro. Em um mesmo Space, um e-mail só pode se cadastrar uma vez. Os preparativos indicados na tabela servem para receber esse e-mail, então não os pule. O procedimento para obter os dois valores varia de um provedor para outro, por isso ele é tratado junto com as telas no guia de conexão da última coluna da tabela.

ProvedorEscopos que a WEEGLOO solicitaO que ativar antes no console do provedorGuia de conexão
Googleemail, profileNadaConectar
GitHubread:user, user:emailNadaConectar
Facebookemail, public_profileÉ preciso adicionar email em Permissions and features do appConectar
GitLabread_userMarque read_user nos escopos ao criar o appConectar
Kakaoprofile_nickname, profile_image, account_emailApós converter o app em Biz App, é necessária a aprovação de uso do item de consentimento de e-mailConectar
Naveremail, profile, nicknameÉ preciso incluir o endereço de e-mail nas informações fornecidas ao registrar o appConectar
LINEprofile, emailÉ preciso solicitar a permissão de e-mail no canal e obter a aprovaçãoConectar

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í.

Na mesma tela você pode bloquear o login de um membro, dar permissões diferentes a um só ou remover um membro da lista. Os passos de cada caso estão em Gerenciar membros do serviço.

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 Role predefinido 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.