Então, por que não usar logins sociais?
1 curtida
Então, por que não usar logins sociais?
Verdade, isso abrange muitas pessoas. Mas há um número crescente de pessoas como eu que não usam login social por falta de confiança nos provedores de login. Os principais provedores são algumas das empresas menos confiáveis do planeta.
E o login social não resolve o problema de pessoas que simplesmente não querem se tornar membros de uma comunidade sobre a qual ainda não sabem nada. Voltando ao meu exemplo original, cheguei a esta comunidade pelo Google procurando informações muito específicas. Eu ainda não tenho nenhum interesse em fazer parte da comunidade que gerou a informação. Manter contato pelo método de menor esforço disponível dá à comunidade a chance de mostrar valor e trazer essa pessoa para o grupo.
O login social é uma solução para a barreira técnica, não para a barreira psicológica.
3 curtidas
E, no entanto, todas as listas de e-mail funcionam dessa maneira.
Se o e-mail que o usuário insere for o mesmo do login social, e considerando que a permissão solicitada ao autenticar via login social, além de dados públicos (que já são públicos), é o endereço de e-mail, então não vejo problema com o login social.
Por exemplo, normalmente me autentico com Google ou GitHub, e quando a permissão é solicitada, apenas me certifico de que apenas o e-mail seja solicitado. Neste caso, considero muito mais conveniente do que inserir o endereço de e-mail, pois não preciso digitá-lo (e com login por e-mail, possivelmente também terei que validar o e-mail). Com login social, são apenas 1 ou 2 cliques.
Na verdade, é muito mais provável que eu me inscreva em uma newsletter (ou coisas semelhantes) via login social do que inserindo o e-mail. Claro, este é o meu caso específico.
Respondendo à minha própria resposta.
Não encontrei nenhuma opção de registro sem senha no diretório de plugins. Encontrei este tópico onde @codinghorror levantou algumas objeções à ideia: Why is password still required at signup? Não concordo com elas, mas parece que foi o fim da discussão sobre essa ideia.
Parece que é hora de desempoeirar meu livro de Ruby ou postar em Marketplace.
Eu dei uma olhada nos endpoints de API existentes. Parece que, para realizar o que descrevi acima, eu precisaria de um plugin que combine a funcionalidade destes dois endpoints:
POST /users.json
Request:
{
"name": "string",
"email": "string",
"password": "string",
"username": "string",
"active": true,
"approved": true,
"user_fields[1]": true
}
POST /t/{id}/notifications.json
Request:
{
"notification_level": "0"
}
em:
POST /plugin-name/users.json
Request:
{
"email": "string",
"name": "string", // agora opcional
"password": "string", // agora opcional
"username": "string", // agora opcional
"active": true,
"approved": true,
"user_fields[1]": true,
"notifications": [ // nova propriedade
{
"topic_id": "some-topic-id",
"notification_level": "0"
}
]
}
Essa nova lógica seria adicionada:
- se o nome for nulo, gere um automaticamente
- se o nome de usuário for nulo, gere um automaticamente. Possivelmente apenas defina como um uuid
- se a senha for nula, defina como um uuid do tipo 4 ou apenas uma string aleatória
- se len(notifications) > 0, adicione uma entrada de notificação ao banco de dados
Além disso, alguma informação sobre como definir seu próprio nome de usuário, nome e senha deve ser adicionada ao e-mail de boas-vindas. Isso é fácil porque a maior parte está em https://example.com/u/{username}/preferences/account. Isso poderia ser apenas um novo parágrafo a ser inserido.
Então, é claro, você precisaria de um componente de UI que, no mínimo, tenha:
- um campo de e-mail
- uma caixa de seleção ‘Assistir a este tópico’
- um botão de envio
Para fins de GDPR, seria uma boa ideia adicionar também um link para uma página de documentação sobre exatamente o que ‘Assistir’ significa, quais e-mails eles receberão, etc.
3 curtidas
Já existe código para criar usuários “staged” se você permitir a criação de tópicos por e-mail. Eles têm um nome de usuário aleatório e cada um está associado a um endereço de e-mail. Você pode “reivindicar” a conta fazendo login e validando esse endereço de e-mail.
Veja
Talvez construir sobre isso ajude?
3 curtidas
Obrigado pela dica. Na verdade, parece perfeito.
Vou investigar o código e ver se consigo chamar diretamente o código que cria o usuário em staging ao receber o e-mail.
1 curtida
Sim, esse foi meu processo de pensamento original, mas active pode não ser a propriedade mais útil.
Um usuário completo staged = false, active = true, então esses são atributos diferentes (nota para mim mesmo!)
Sugestão promissora @mattdm … pode reduzir significativamente o trabalho envolvido!
3 curtidas
Passei um bom tempo vasculhando o código. Acho que algo assim (aviso: muito provavelmente não está funcionando, pois ainda não tentei) funcionaria para permitir que o usuário poste uma resposta apenas com um e-mail. Agradeceria quaisquer comentários que você tiver.
Não tenho certeza se esta é a melhor maneira de criar um usuário em estágio. Não encontrei nenhum método que crie especificamente usuários em estágio, no entanto.
class SomePluginController < ApplicationController
# Certifique-se de que há um usuário em estágio no banco de dados
def ensure_user
# Veja se o usuário em estágio existe
user = User.where(staged: true).with_email(params[:email].strip.downcase).first
# Crie um usuário em estágio manualmente
if !user
user = User.new
user.staged = true
user.email = params[:email]
user.active = false
user.save!
end
user
end
# Assista ao tópico como um usuário em estágio
def staged_watch
user = ensure_user
topic = Topic.find(params[:topic_id].to_i)
TopicUser.change(user, topic.id, notification_level: params[:notification_level].to_i)
end
# Responda ao tópico como um usuário em estágio
def staged_reply
user = ensure_user
manager = NewPostManager.new(user,
raw: params[:body],
topic_id: params[:topic_id])
result = manager.perform
end
end
3 curtidas
Esta conversa alguma vez se materializou em um plugin ou em um processo descoberto que utiliza Usuários em Estágio?
1 curtida