Warum also keine sozialen Logins verwenden?
1 „Gefällt mir“
„Warum also keine Social-Logins verwenden?“
Stimmt, das deckt viele Leute ab. Aber es gibt eine wachsende Zahl von Leuten wie mir, die Social-Logins aus Misstrauen gegenüber den Login-Anbietern nicht nutzen. Die Hauptanbieter gehören zu den am wenigsten vertrauenswürdigen Unternehmen der Welt.
Und Social-Login löst nicht das Problem, dass Leute einfach kein Mitglied einer Community werden wollen, über die sie noch nichts wissen. Um auf mein ursprüngliches Beispiel zurückzukommen: Ich bin über Google zu dieser Community gekommen, weil ich nach sehr spezifischen Informationen gesucht habe. Ich habe noch kein Interesse daran, Teil der Community zu sein, die die Informationen generiert hat. Über die am wenigsten aufwändige Methode in Kontakt zu bleiben, gibt der Community die Chance, Wert zu zeigen und diese Person für sich zu gewinnen.
Social-Login ist eine Lösung für die technische Barriere, nicht für die psychologische Barriere.
3 „Gefällt mir“
Und doch funktionieren alle E-Mail-Listen auf diese Weise.
Wenn die vom Benutzer eingegebene E-Mail-Adresse mit der E-Mail-Adresse des Social Logins übereinstimmt und unter Berücksichtigung der Berechtigungen, die bei der Authentifizierung über Social Login angefordert werden (abgesehen von öffentlichen Daten, die bereits öffentlich sind), die E-Mail-Adresse ist, dann sehe ich kein Problem mit dem Social Login.
Zum Beispiel authentifiziere ich mich normalerweise mit Google oder GitHub, und wenn die Berechtigung angefordert wird, stelle ich nur sicher, dass nur die E-Mail-Adresse angefordert wird. In diesem Fall halte ich es für viel bequemer, als die E-Mail-Adresse einzugeben (und mit E-Mail-Login muss ich die E-Mail möglicherweise auch validieren). Mit Social Login sind es nur 1 oder 2 Klicks.
Tatsächlich ist es viel wahrscheinlicher, dass ich einen Newsletter (oder ähnliches) über einen Social Login abonniere, als meine E-Mail-Adresse einzugeben. Dies ist natürlich mein spezieller Fall.
Antworte auf meine eigene Antwort.
Ich bin im Plugin-Verzeichnis auf keine passwortlosen Registrierungsoptionen gestoßen. Ich habe dieses Thema gefunden, in dem @codinghorror einige Einwände gegen die Idee hatte: Why is password still required at signup? Ich stimme ihnen nicht zu, aber das schien das Ende der Diskussion über diese Idee gewesen zu sein.
Es sieht so aus, als wäre es an der Zeit, entweder mein Ruby-Buch abzustauben oder auf Marketplace zu posten.
Ich habe mir die vorhandenen API-Endpunkte angesehen. Um das oben beschriebene zu erreichen, bräuchte ich ein Plugin, das die Funktionalität dieser beiden Endpunkte kombiniert:
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"
}
in:
POST /plugin-name/users.json
Request:
{
"email": "string",
"name": "string", // jetzt optional
"password": "string", // jetzt optional
"username": "string", // jetzt optional
"active": true,
"approved": true,
"user_fields[1]": true,
"notifications": [ // neue Eigenschaft
{
"topic_id": "some-topic-id",
"notification_level": "0"
}
]
}
Diese neue Logik würde hinzugefügt werden:
- Wenn der Name null ist, wird automatisch einer generiert.
- Wenn der Benutzername null ist, wird automatisch einer generiert. Möglicherweise wird einfach eine UUID festgelegt.
- Wenn das Passwort null ist, wird eine UUID vom Typ 4 oder einfach eine zufällige Zeichenfolge festgelegt.
- Wenn len(notifications) > 0 ist, wird ein Benachrichtigungseintrag in die Datenbank eingefügt.
Zusätzlich sollten in der Willkommens-E-Mail einige Informationen darüber hinzugefügt werden, wie man seinen eigenen Benutzernamen, Namen und sein Passwort festlegt. Das ist einfach, da die meisten davon unter https://example.com/u/{username}/preferences/account zu finden sind. Dies könnte einfach ein neuer Absatz sein, der eingefügt wird.
Dann bräuchte man natürlich eine UI-Komponente, die mindestens Folgendes enthält:
- ein E-Mail-Feld
- eine Checkbox “Diese Themen verfolgen”
- eine Schaltfläche zum Absenden
Zu GDPR-Zwecken wäre es auch ratsam, einen Link zu einer Dokumentationsseite hinzuzufügen, die genau erklärt, was “Verfolgen” bedeutet, welche E-Mails sie erhalten werden usw.
3 „Gefällt mir“
Es gibt bereits Code, um “gestufte” Benutzer zu erstellen, wenn Sie zulassen, dass Themen per E-Mail erstellt werden. Diese haben einen zufälligen Benutzernamen und sind jeweils mit einer E-Mail-Adresse verknüpft. Sie können das Konto “beanspruchen”, indem Sie sich anmelden und diese E-Mail-Adresse bestätigen.
Siehe
Vielleicht hilft es, darauf aufzubauen?
3 „Gefällt mir“
Danke für den Hinweis. Das sieht tatsächlich perfekt aus.
Ich werde mich mit dem Code befassen und sehen, ob ich den Code, der den Staging-Benutzer bei Emailempfang erstellt, direkt aufrufen kann.
1 „Gefällt mir“
Ja, das war mein ursprünglicher Gedankengang, aber active ist möglicherweise nicht die nützlichste Eigenschaft.
Ein vollständiger Benutzer ist staged = false, active = true, also sind dies unterschiedliche Attribute (Notiz an mich selbst!)
Vielversprechender Vorschlag @mattdm … könnte die damit verbundene Arbeit erheblich reduzieren!
3 „Gefällt mir“
Ich habe einige Zeit damit verbracht, den Code zu durchforsten. Ich glaube, so etwas (Warnung: sehr wahrscheinlich funktioniert es nicht, da ich es noch nicht ausprobiert habe) würde funktionieren, um dem Benutzer zu ermöglichen, eine Antwort nur mit einer E-Mail zu posten. Ich würde mich über Ihre Kommentare freuen.
Ich bin mir besonders nicht sicher, ob dies der beste Weg ist, einen gestuften Benutzer zu erstellen. Ich habe jedoch keine Methode gefunden, die speziell gestufte Benutzer erstellt.
class SomePluginController < ApplicationController
# Stellen Sie sicher, dass ein gestufter Benutzer in der Datenbank vorhanden ist
def ensure_user
# Prüfen Sie, ob ein gestufter Benutzer vorhanden ist
user = User.where(staged: true).with_email(params[:email].strip.downcase).first
# Erstellen Sie manuell einen gestuften Benutzer
if !user
user = User.new
user.staged = true
user.email = params[:email]
user.active = false
user.save!
end
user
end
# Thema als gestufter Benutzer beobachten
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
# Auf Thema als gestufter Benutzer antworten
def staged_reply
user = ensure_user
manager = NewPostManager.new(user,
raw: params[:body],
topic_id: params[:topic_id])
result = manager.perform
end
end
3 „Gefällt mir“
Hat sich dieses Gespräch jemals zu einem Plugin oder einem entdeckten Prozess entwickelt, der Staged Users nutzt?
1 „Gefällt mir“