للمزيد من المعلومات:
تم إضافة إعداد خيار جديد يُسمى invite_code.
عند تعيينه، يجب على جميع الحسابات المسجلة إدخال رمز الدعوة للسماح بإنشاء الحساب. لا يُسمح للمستخدمين الذين لا يملكون هذا الرمز بتسجيل حساب.
إذا كان رمز الدعوة غير صحيح، سيظهر للمستخدم رسالة خطأ مفيدة:
هذه الميزة إضافية بنسبة 100%. حاليًا، فهي متوافقة فقط مع المصادقة المحلية، لكننا سنقوم بتحسين ذلك في الإصدارات المستقبلية.
إذا قمت بتفعيل رمز الدعوة العام، فإنه يُطبق؛ وإلا فلن يُطبق، ولن يظهر رمز الدعوة في نافذة التسجيل.
كيف يمكن أن يكون هذا منطقيًا؟ ألا ينبغي أن يسمح الكود بتجاوز موافقة الموظفين على الحسابات الجديدة؟
الكود لا يتعلق بالموظفين أو غير الموظفين، بل هو بنسبة 100% يتعلق بتسجيل حسابات جديدة.
حالة الاستخدام هي النشر على واتساب أو مجموعة خاصة على فيسبوك…
مرحبًا، لقد قمت بإعداد منتدى لك، استخدم رمز الدعوة “مرحبًا بكم في ديسكورس” لتسجيل حساب.
بما أن الموقع يتطلب التسجيل، فإن الوصول مسموح به فقط للأشخاص الذين يملكون الرمز.
يمكننا بالتأكيد توسيع هذا النطاق، لكن لدي حالة استخدام عاجلة للغاية لهذا الغرض، لذا قمت بإنجازه اليوم وسأقوم بتحسينه الأسبوع المقبل.
أنا لا أفهم حقًا حالة الاستخدام لهذه الميزة!
لماذا لا نفعّل موافقات الحسابات الجديدة ونوجه الأشخاص إلى الموقع؟
يتطلب ذلك تدخلاً يدوياً لمراجعة كل حساب. هذا الإعداد مفيد جداً لأولئك الذين يرغبون في تجربة النظام مع عدد قليل من المستخدمين، أو لأولئك الذين يديرون نوعاً من العروض الترويجية حيث يكون الوصول إلى المنتدى ميزة إضافية. مثل هذا رمز الدعوة سيقلل بشكل كبير من أعباء العمل في منتديات المشاريع التجريبية أيضاً.
لأنني بحاجة إلى الموافقة على كل بريد إلكتروني على حدة والبقاء في قائمة الانتظار للموافقة على مدار الساعة طوال أيام الأسبوع، ولا أعرف ما إذا كان هذا بوت عشوائي مسجّل أو شخصًا حقيقيًا يجب أن يكون لديه حق الوصول أم لا.
مع رمز دعوة، أعرف على الأقل أنهم حصلوا على رمز دعوة قمت بمشاركته بشكل خاص.
ولكن أليس هذا هو الهدف الرئيسي من اعتماد المستخدمين؟
سيساعدنا هذا أيضًا في منصة استجابتنا لـ COVID-19 - نعم، من فضلك، بأسرع وقت ممكن!!!
+1 لهذه الميزة، التي تُعد مفيدة للغاية للعديد من المجتمعات التي أديرها. أفهم وجهة نظر @codinghorror و @ondrej حول الموافقة اليدوية المذكورة أعلاه، لكنني أعتقد أن هذه الميزة تسد فجوة موجودة بين دعوة الجميع يدويًا (موقع «دعوة فقط») والموافقة على الجميع يدويًا (موقع «اعتماد المستخدمين»).
لا نرغب في الموافقة على المستخدمين. نريد فقط نشر رمز في مجموعة على Slack أو Telegram أو WhatsApp والسماح للجميع باستخدامه. أحيانًا، لا يضر وجود عدد قليل من الاختباريين الإضافيين قبل الإطلاق الرسمي.
نعم، ستكون هذه الميزة مفيدة للغاية في الوقت الحالي! 
أجد هذا مفيدًا للغاية أيضًا، خاصةً إذا تم توسيع الوظيفة قليلاً لتمكين “ربط” المجموعات بكود دعوة محدد، أي أن شخصًا ما ينشئ حسابًا باستخدام كود محدد يُضاف تلقائيًا إلى مجموعة محددة.
في بعض حالات الاستخدام، قد يحل هذا أيضًا طلبًا يتكرر بين الحين والآخر يتعلق برموز دعوة مستقلة عن البريد الإلكتروني…
كيف يختلف هذا جوهريًا عن
على الأقل كانوا يملكون رابط URL قمتُ بمشاركة خاصة به
لأنه بصراحة، بالطريقة التي هي عليها الآن، لا أفهم هذه الميزة على الإطلاق.
يُعد وجود خيار إدخال رمز تجاوز أو موافقة المسؤول هو الخيار الأكثر منطقية هنا.
أنا معجب بهذا في أشكال مختلفة قليلاً، إنه يحتاج فقط إلى بعض التعديلات. إذا كانت هناك حاجة عاجلة (?) له الآن، فأعتقد أن هذا مقبول؟
أنا شخصياً لا أشعر أن السحر النطاق …
يرجى التسجيل في
https://forum.this-is-my-magic-domain.org
هو مستوى حماية تسجيل مستحيل الاستخدام تماماً وغير قابل للعمل مقارنة بالسحر كلمة المرور …
يجب أن تعرف السري
this-is-my-magic-passwordللوصول إلى هذا الموقع
هناك شكلان من هذا الشكل الذي يسعدني جدًا دعمهما
يرجى زيارة
amazing.forum.comوإدخال رمز الدعوة:fantasticللحصول على الوصول (تم تنفيذه)
و
يرجى زيارة
amazing.forum.com/register?code=fantasticللتسجيل والحصول على الوصول إلى المنتدى
من المحتمل أننا تجاوزنا قاعدة الـ 100 هنا نظرًا لأن الطريقة العامة التي نستخدمها لحل هذه المشكلة هي وضع المواقع خلف مصادقة HTTP الأساسية.
كلاهما متشابهان إلى حد كبير، سأقوم بتنفيذ الخيار الأول حاليًا لكنني سأعود لتنفيذ الخيار الثاني لاحقًا.
الخيار الأول له ميزة أنه أسهل قليلاً عندما لا تعتمد على النسخ واللصق، على سبيل المثال، احصل على التعليمات عبر واتساب ثم استخدم سطح المكتب لإكمال العملية.
الخيار الثاني له ميزة أنه يقلل من كتابة fantastic وهو مفيد للمشاركة عبر “البريد الإلكتروني” مقارنة بالمشاركة عبر واتساب.
هل لا تتابع من أين جاء forum.this-magic-domain.org هنا؟ في كلتا الحالتين، هذا هو نفس النطاق تمامًا الذي يستضيفه المنتدى.
إليك مسودة سريعة لما كنت أتخيل أن واجهة المستخدم ستبدو عليه لهذا:
(هذا على موقع تطوير مع تفعيل must_approve_users، بعد التحقق من البريد الإلكتروني)
يجب أن يكون اختياريًا عند التسجيل، واختياريًا عند تسجيل الدخول قبل الموافقة، لأن أي إجراء يفرض على جميع المستخدمين نسخ الكود وتوزيعه سيؤدي إلى تعطل النظام ويتطلب تدخّل المسؤول.
كلا، من المؤكد أنه سيؤدي إلى تسريب البيانات. https://www.farsightsecurity.com/technical/passive-dns/passive-dns-faq/#q11
يمكن أن يعمل هذا للإعدادات المحدودة زمنيًا، لكنه ليس مناسبًا كاستراتيجية طويلة الأمد.
لماذا تحتاج إلى رمز موافقة بعد أن أنشأت حسابًا بالفعل؟
هل يعني ذلك أن الروبوتات تقوم فقط بتسجيل حسابات غير مجدية يمكنك القضاء عليها قبل أن تلوث قاعدة بياناتك؟
بالإضافة إلى ذلك، حسابك مسجل بالفعل، وقد يكون قد تم التحقق منه.
أيضًا، ما هذا الضجيج حول النطاقات السرية؟
إذا قمنا بتفعيل هذا على ميتا، على سبيل المثال:
يرجى زيارة meta.discourse.org وإدخال الرمز HELLOMETA لإنشاء حساب.
أدرك الآن أنني قمت فقط بتكرار نقاط @codinghorror من الموضوع السابق عن طريق الخطأ. (والذي لم أقرأه وقت الكتابة، لأن هذا كان في #feature:announcements)
بشكل أساسي، يجب أن يُبنى هذا فوق must_approve_users + login_required بدلاً من إنشاء نظام موازٍ بالكامل. التنفيذ الحالي جيد كحل مؤقت لاجتياز الأزمة الحالية، لكنه يحتاج إلى إصلاح.
سيُنسى شخص ما الكود أو لن يكتبه إذا عرضته في مؤتمر. أو ستحتاج إلى تحديث الكود بعد نشر فيديوهات المؤتمر. من الأفضل بكثير أن تسأل في مجموعة الواتساب الخاصة بك “من حساب @test3؟”، تحصل على إجابة مؤكدة، ثم تضغط
بدلاً من محاولة توجيههم لنسخ الكود في نموذج التسجيل بشكل صحيح. (ملاحظة: هذه لقطات الشاشة بعد التحقق من البريد الإلكتروني.)
أعتقد أن الأمر على ما يرام، نحن بحاجة فقط إلى الوصول إلى التعديلات النهائية. هناك بالتأكيد بعض التحسينات التي أؤيدها تمامًا هنا.
أولاً، التكامل مع صفحة دعوات المستخدمين، على سبيل المثال، إذا قمت بالتسجيل عبر meta عن طريق زيارة الرابط https://meta.discourse.org/signup?u=codinghorror، فستظهر كشخص دعوتُته في صفحة ملفي الشخصي، مثل هذا:
تذكر أن الدعوات القائمة على البريد الإلكتروني تمنح بالفعل مستوى الثقة 1 (TL1) لأولئك المستخدمين الذين دعوتهم… لذا فإن هذه الميزة موجودة بالفعل… راجع نافذة الحوار الخاصة بالدعوة… لاحظ أنه يمكنك إضافة وصول المجموعة أيضًا، وارتفاع مستوى الثقة (TL) ضمني. ربما يجب أن نوضح ذلك في النص هنا في هذه النافذة، في الواقع:
ثانيًا، يجب أن تكون قادرًا على إنشاء روابط دعوة بدون بريد إلكتروني من نفس المكان الذي ترسل فيه الدعوات، وفقًا لما ورد أعلاه 
.. هذا يحل تمامًا مشكلة “لكنني لا أعرف عناوين بريدهم الإلكتروني 
”.
ثالثًا، أعتقد أنه من المقبول أن يكون الموقع “بدعوة فقط” وأن تكون جميع الدعوات على شكل روابط تشعبية بالإضافة إلى كلمة سر سرية. بهذه الطريقة يكون الأمر:
open sesame)وإذا كان موقعك يتطلب الموافقات، فإن كلمة السر السرية تسمح لك بتجاوز عملية الموافقة أيضًا. وإذا لم تكن لديك موافقات، فلا يمكنك الدخول بدون كلمة السر السرية…
مشكلتي الرئيسية هي أننا لا نتكامل مع الميزات الموجودة هنا، بل نضيف بعض الأشياء العشوائية من خلال إعداد موقع غامض. لكن يمكننا التكامل لجعل ميزة الدعوة أفضل بكثير بدلاً من أن تكون إعداد موقع منفصلًا وغريبًا.