إذًا، لماذا لا تستخدم تسجيلات الدخول الاجتماعية؟
إعجاب واحد (1)
إذن لماذا لا تستخدم تسجيل الدخول الاجتماعي؟
صحيح، هذا يغطي الكثير من الناس. ولكن هناك عدد متزايد من الأشخاص مثلي لا يستخدمون تسجيل الدخول الاجتماعي خوفًا من عدم الثقة في مزودي تسجيل الدخول. المزودون الرئيسيون هم بعض الشركات الأقل ثقة على هذا الكوكب.
ولا يعالج تسجيل الدخول الاجتماعي مسألة عدم رغبة الأشخاص ببساطة في أن يصبحوا أعضاء في مجتمع لا يعرفون عنه شيئًا بعد. بالعودة إلى مثالي الأصلي، جئت إلى هذا المجتمع عبر جوجل بحثًا عن معلومات محددة جدًا. ليس لدي حاليًا أي اهتمام بأن أكون جزءًا من المجتمع الذي أنتج المعلومات. البقاء على اتصال عبر الطريقة الأقل جهدًا المتاحة يمنح المجتمع فرصة لإظهار القيمة وجذب هذا الشخص.
تسجيل الدخول الاجتماعي هو حل للحاجز التقني، وليس الحاجز النفسي.
3 إعجابات
ومع ذلك، فإن جميع القوائم البريدية تعمل بهذه الطريقة.
إذا كان البريد الإلكتروني الذي يدخله المستخدم هو نفسه البريد الإلكتروني من تسجيل الدخول الاجتماعي، ومع الأخذ في الاعتبار أن الإذن المطلوب عند المصادقة عبر تسجيل الدخول الاجتماعي، بخلاف البيانات العامة (التي هي بالفعل عامة)، هو عنوان البريد الإلكتروني، فلن أرى مشكلة في تسجيل الدخول الاجتماعي.
على سبيل المثال، أقوم عادةً بالمصادقة باستخدام Google أو GitHub، وعندما يُطلب الإذن، أتأكد فقط من طلب البريد الإلكتروني فقط. في هذه الحالة، أعتبره أكثر ملاءمة من إدخال عنوان البريد الإلكتروني، لأنني لست مضطرًا لكتابته (ومع تسجيل الدخول عبر البريد الإلكتروني، قد أحتاج أيضًا إلى التحقق من صحة البريد الإلكتروني). مع تسجيل الدخول الاجتماعي، يكون الأمر نقرة واحدة أو نقرتين.
في الواقع، من المرجح جدًا أن أشترك في رسالة إخبارية (أو أشياء مماثلة) عبر تسجيل الدخول الاجتماعي بدلاً من إدخال البريد الإلكتروني. بالطبع، هذه حالتي الخاصة.
بالرد على ردي الخاص.
لم أتوصل إلى أي خيارات تسجيل بدون كلمة مرور في دليل الإضافات. لقد وجدت هذا الموضوع حيث لدى @codinghorror بعض الاعتراضات على الفكرة: Why is password still required at signup? لا أتفق معهم، ولكن يبدو أن هذا كان نهاية المناقشة حول هذه الفكرة.
يبدو أن الوقت قد حان إما لغبار كتاب Ruby الخاص بي أو النشر على Marketplace
لقد ألقيت نظرة على نقاط نهاية واجهة برمجة التطبيقات (API) الحالية. يبدو أنه لتحقيق ما وضعته أعلاه، سأحتاج إلى مكون إضافي يجمع الوظائف من نقطتي النهاية هاتين:
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"
}
إلى:
POST /plugin-name/users.json
Request:
{
"email": "string",
"name": "string", // اختياري الآن
"password": "string", // اختياري الآن
"username": "string", // اختياري الآن
"active": true,
"approved": true,
"user_fields[1]": true,
"notifications": [ // خاصية جديدة
{
"topic_id": "some-topic-id",
"notification_level": "0"
}
]
}
ستتم إضافة هذا المنطق الجديد:
- إذا كان الاسم فارغًا (null)، فسيتم إنشاؤه تلقائيًا.
- إذا كان اسم المستخدم فارغًا (null)، فسيتم إنشاؤه تلقائيًا. ربما يتم تعيينه ببساطة إلى معرف فريد عالمي (uuid).
- إذا كانت كلمة المرور فارغة (null)، فسيتم تعيينها إلى معرف فريد عالمي (uuid) من النوع 4 أو مجرد سلسلة عشوائية.
- إذا كان طول الإشعارات (notifications) أكبر من 0، فستتم إضافة إدخال إشعار إلى قاعدة البيانات.
بالإضافة إلى ذلك، يجب إضافة بعض المعلومات حول كيفية تعيين اسم المستخدم والاسم وكلمة المرور الخاصة بك إلى البريد الإلكتروني الترحيبي. هذا سهل لأن معظمها موجود في https://example.com/u/{username}/preferences/account. يمكن أن تكون هذه مجرد فقرة جديدة يتم إدراجها.
ثم بالطبع ستحتاج إلى مكون واجهة مستخدم (UI) يحتوي على الأقل على:
- حقل بريد إلكتروني
- مربع اختيار “متابعة هذا الموضوع”
- زر إرسال
لأغراض اللائحة العامة لحماية البيانات (GDPR)، سيكون من الجيد أيضًا إضافة رابط إلى صفحة وثائق توضح بالضبط ما يعنيه “المتابعة”، وما هي رسائل البريد الإلكتروني التي سيتلقونها، وما إلى ذلك.
3 إعجابات
يوجد بالفعل رمز لإنشاء مستخدمين “مرحلين” إذا سمحت بإنشاء مواضيع عبر البريد الإلكتروني. هؤلاء لديهم اسم مستخدم عشوائي ويرتبط كل منهم بعنوان بريد إلكتروني. يمكنك “المطالبة” بالحساب عن طريق تسجيل الدخول والتحقق من صحة عنوان البريد الإلكتروني هذا.
انظر
ربما يساعد البناء على هذا؟
3 إعجابات
شكراً على الإشارة. هذا يبدو مثالياً بالفعل.
سأتعمق في الكود وأرى ما إذا كان بإمكاني استدعاء الكود الذي ينشئ المستخدم المرحلي مباشرة عند استلام البريد الإلكتروني.
إعجاب واحد (1)
نعم، كانت هذه هي عملية تفكيري الأصلية ولكن خاصية Active قد لا تكون الأكثر فائدة.
المستخدم الكامل staged = false, active = true, لذا هذه سمات مختلفة (ملاحظة لنفسي!)
اقتراح واعد يا @mattdm … قد يقلل بشكل كبير من العمل المطلوب!
3 إعجابات
لقد قضيت بعض الوقت الجيد في البحث في الكود. أعتقد أن شيئًا كهذا (تحذير: من المحتمل جدًا ألا يعمل لأنني لم أجربه بعد) سيعمل للسماح للمستخدم بنشر رد باستخدام البريد الإلكتروني فقط. سأكون ممتنًا لأي تعليقات لديك.
أنا لست متأكدًا بشكل خاص مما إذا كانت هذه هي أفضل طريقة لإنشاء مستخدم مرحلي. لم أجد أي طريقة تنشئ مستخدمين مرحليين على وجه التحديد على الرغم من ذلك.
class SomePluginController < ApplicationController
# تأكد من وجود مستخدم مرحلي في قاعدة البيانات
def ensure_user
# تحقق مما إذا كان المستخدم المرحلي موجودًا
user = User.where(staged: true).with_email(params[:email].strip.downcase).first
# إنشاء مستخدم مرحلي يدويًا
if !user
user = User.new
user.staged = true
user.email = params[:email]
user.active = false
user.save!
end
user
end
# مشاهدة الموضوع كمستخدم مرحلي
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
# الرد على الموضوع كمستخدم مرحلي
def staged_reply
user = ensure_user
manager = NewPostManager.new(user,
raw: params[:body],
topic_id: params[:topic_id])
result = manager.perform
end
end
3 إعجابات
هل تجسدت هذه المحادثة في أي وقت مضى في إضافة أو عملية مكتشفة تستخدم المستخدمين المرحليين؟
إعجاب واحد (1)