Alors pourquoi ne pas utiliser les connexions sociales ?
1 « J'aime »
Alors pourquoi ne pas utiliser les connexions sociales ?
C’est vrai, cela couvre beaucoup de monde. Mais il y a un nombre croissant de personnes comme moi qui n’utilisent pas la connexion sociale par manque de confiance envers les fournisseurs de connexion. Les principaux fournisseurs sont parmi les entreprises les moins fiables de la planète.
Et la connexion sociale ne résout pas le problème des personnes qui ne veulent tout simplement pas devenir membres d’une communauté dont elles ne savent encore rien. Pour revenir à mon exemple initial, je suis arrivé dans cette communauté via Google à la recherche d’informations très spécifiques. Je n’ai pas encore le moindre intérêt à faire partie de la communauté qui a généré l’information. Rester en contact par la méthode la plus simple disponible donne à la communauté la chance de montrer sa valeur et d’intégrer cette personne.
La connexion sociale est une solution à la barrière technique, pas à la barrière psychologique.
3 « J'aime »
Et pourtant, toutes les listes de diffusion fonctionnent ainsi.
Si l’e-mail que l’utilisateur saisit est le même que l’e-mail de la connexion sociale, et en considérant que la permission demandée lors de l’authentification via la connexion sociale, autre que les données publiques (qui sont déjà publiques), est l’adresse e-mail, alors je ne vois pas de problème avec la connexion sociale.
Par exemple, je m’authentifie normalement avec Google ou GitHub, et lorsque la permission est demandée, je m’assure uniquement que seul l’e-mail est demandé. Dans ce cas, je trouve cela beaucoup plus pratique que de saisir l’adresse e-mail, car je n’ai pas à l’écrire (et avec la connexion par e-mail, je devrai peut-être aussi valider l’e-mail). Avec la connexion sociale, il suffit d’un ou deux clics.
En fait, il est beaucoup plus probable que je m’abonne à une newsletter (ou des choses similaires) via une connexion sociale plutôt qu’en saisissant mon adresse e-mail. Bien sûr, c’est mon cas particulier.
Répondre à ma propre réponse.
Je n’ai trouvé aucune option d’inscription sans mot de passe dans le répertoire des plugins. J’ai trouvé ce sujet où @codinghorror soulève quelques objections à l’idée : Why is password still required at signup? Je ne suis pas d’accord avec lui, mais cela semble avoir mis fin à la discussion sur cette idée.
Il semble qu’il soit temps soit de dépoussiérer mon livre de Ruby, soit de poster sur Marketplace.
J’ai examiné les points d’accès API existants. Il semble que pour accomplir ce que j’ai décrit ci-dessus, j’aurais besoin d’un plugin qui combine les fonctionnalités de ces deux points d’accès :
POST /users.json
Requête :
{
"name": "string",
"email": "string",
"password": "string",
"username": "string",
"active": true,
"approved": true,
"user_fields[1]": true
}
POST /t/{id}/notifications.json
Requête :
{
"notification_level": "0"
}
en :
POST /plugin-name/users.json
Requête :
{
"email": "string",
"name": "string", // maintenant optionnel
"password": "string", // maintenant optionnel
"username": "string", // maintenant optionnel
"active": true,
"approved": true,
"user_fields[1]": true,
"notifications": [ // nouvelle propriété
{
"topic_id": "some-topic-id",
"notification_level": "0"
}
]
}
Cette nouvelle logique serait ajoutée :
- si le nom est nul, en générer un automatiquement
- si le nom d’utilisateur est nul, en générer un automatiquement. Peut-être simplement définir sur un uuid
- si le mot de passe est nul, définir sur un uuid de type 4 ou simplement une chaîne aléatoire
- si len(notifications) > 0, ajouter une entrée de notification à la base de données
De plus, des informations sur la manière de définir son propre nom d’utilisateur, nom et mot de passe devraient être ajoutées à l’e-mail de bienvenue. C’est facile car la plupart de ces informations se trouvent sur https://example.com/u/{username}/preferences/account. Cela pourrait simplement être un nouveau paragraphe à insérer.
Ensuite, il faudrait bien sûr un composant d’interface utilisateur qui, au minimum, contienne :
- un champ e-mail
- une case à cocher “Suivre ce sujet”
- un bouton de soumission
Pour des raisons de RGPD, il serait également judicieux d’ajouter un lien vers une page de documentation expliquant exactement ce que signifie “Suivre”, quels e-mails ils recevront, etc.
3 « J'aime »
Il y a déjà du code pour créer des utilisateurs « staged » si vous autorisez la création de sujets par e-mail. Ceux-ci ont un nom d’utilisateur aléatoire et sont chacun associés à une adresse e-mail. Vous pouvez « revendiquer » le compte en vous connectant et en validant cette adresse e-mail.
Voir
Peut-être que s’appuyer sur cela pourrait aider ?
3 « J'aime »
Merci pour le tuyau. Cela semble parfait.
Je vais examiner le code et voir si je peux appeler directement le code qui crée l’utilisateur mis en scène lors de la réception de l’e-mail.
1 « J'aime »
Oui, c’était ma réflexion initiale, mais Active n’est peut-être pas la propriété la plus utile.
Un utilisateur complet est staged = false, active = true, ce sont donc des attributs différents (note à moi-même !)
Suggestion prometteuse @mattdm … pourrait bien réduire considérablement le travail à accomplir !
3 « J'aime »
J’ai passé du temps à examiner le code. Je pense que quelque chose comme ceci (attention : il est très probable que cela ne fonctionne pas car je ne l’ai pas encore essayé) fonctionnerait pour permettre à l’utilisateur de poster une réponse avec juste un e-mail. J’apprécierais tous vos commentaires.
Je ne suis pas particulièrement sûr que ce soit la meilleure façon de créer un utilisateur temporaire. Je n’ai trouvé aucune méthode qui crée spécifiquement des utilisateurs temporaires cependant.
class SomePluginController < ApplicationController
# Assurez-vous qu'il y a un utilisateur temporaire dans la base de données
def ensure_user
# Vérifiez si un utilisateur temporaire existe
user = User.where(staged: true).with_email(params[:email].strip.downcase).first
# Créez un utilisateur temporaire manuellement
if !user
user = User.new
user.staged = true
user.email = params[:email]
user.active = false
user.save!
end
user
end
# Suivre un sujet en tant qu'utilisateur temporaire
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
# Répondre à un sujet en tant qu'utilisateur temporaire
def staged_reply
user = ensure_user
manager = NewPostManager.new(user,
raw: params[:body],
topic_id: params[:topic_id])
result = manager.perform
end
end
3 « J'aime »
Cette conversation s’est-elle jamais concrétisée en un plugin ou en un processus découvert utilisant les utilisateurs mis en scène ?
1 « J'aime »