لماذا نعتمد على اعتماد معقد هنا بينما وضع قفل عنوان بريد إلكتروني تافه أبسط بكثير في التطبيق والاستدلال؟ بالإضافة إلى ذلك، هل يفتح هذا الباب أمام ثغرات جديدة؟ لا شكراً!
نظراً لندرة هذه الشكوى والظروف الاستثنائية المحيطة بها، أعتقد أن اتباع المسار الإضافي البسيط الصارم هو المفضل.
المسار البسيط المتمثل في حظر أي شيء لا يطابق /a-zA-Z0-9/ يعمل، لكنه يخلق مشاكل كبيرة في سهولة الاستخدام؛ فكثير من الناس لن يعرفوا كيفية التسجيل، وسيكون علينا إضافة رسائل خطأ جديدة. العديد من مستخدمي Gmail لا يدركون أن janedoe@gmail.com يعمل كبريدهم الإلكتروني، بينما ظنوا دائمًا أن jane.doe@gmail.com هو بريدهم. كما أن هذا الحظر سيؤثر على OAuth ويسبب فشل تسجيل الدخول عبر Gmail لضمان عمله بشكل صحيح.
عنوان البريد الإلكتروني:
sam.s@gmail.com
خطأ: لا يُسمح بنقطة.في عناوين البريد الإلكتروني (رسالة جديدة)
التطبيع أقل عدائية للمستخدم ولا يتطلب أي تجربة مستخدم جديدة.
يمكننا البدء بمُطبع أبسط اختياري (إزالة الوسم، إزالة النقطة في حالة Gmail).
ومع ذلك، ولأكون واضحًا بنسبة 100%، أنا لا أقترح الاعتماد هنا؛ فمكتبة email_address معطلة وغير مناسبة لما نريده هنا.
إجراء نصف متسرع هنا سيؤدي فقط إلى إنشاء إعداد موقع “كسر البريد الإلكتروني في موقعي”، وأنا لست مستعدًا بشكل خاص لإضافته.
صحيح، لكن موقعه تحت الحصار. هناك آلاف الحسابات المكررة التي تسجل يوميًا. لذا من المنطقي أن يكون هناك وضع بسيط لقفل عناوين البريد الإلكتروني، يُقدَّم للمواقع التي تخوض حربًا مع الموساد وتخسر بشدة. الحرب تتطلب تضحيات. ستكون هناك خسائر بين المدنيين. موقعه مكسور بالفعل بشكل رهيب.
في أفضل الحالات، ستحتاج إلى جدول يوضح مزودي البريد الإلكتروني وكيفية “تنظيف” العناوين وفقًا لكل مزود (وهو ما ذكرته بالفعل). كما أوضح بارث بشكل جيد، الأمر لا يتعلق بمنع استخدام أي عنوان بريد إلكتروني بسبب بعض الأحرف، بل بالقدرة على تحديد العناوين التي هي في الواقع نفس العناوين.
بالتأكيد، فالباحثون عن الإزعاج الذين يصرّون على ذلك سيجدون دائمًا طريقة. الأمر يشبه الإنذارات والأقفال واللصوص: الفكرة هي جعل الأمر أكثر صعوبة.
إن إنشاء عناوين بريد إلكتروني متعددة على Gmail يُعد إزعاجًا لـ Gmail، وهي مشكلة عليهم معالجتها (حتى لو تم استخدامها لاحقًا لإزعاجك).
أنا لا أفهم المقصود.
إذا كنا نتعامل مع bob.test+100@gmail.com على أنه bobtest@gmail.com داخليًا ونخزنه بهذه الطريقة (عند تفعيل المفتاح)، فما التضحية المحددة التي تُقدَّم هنا؟
المشكلة محددة في gmail، لذا يبدو لي أن حظر جميع النقاط في كل مكان هو رد فعل مبالغ فيه لأن غوغل قررت ابتكار مواصفة وتطبيعها. منطق التنظيف في الواقع واضح جدًا، وهذا الخيار سيكون افتراضيًا معطلًا.
@Mevo، فقط للتوضيح بنسبة 100%، الاقتراح الذي قدمه جيف هنا هو أن نضيف “وضع الكوارث”؛ في وضع الكوارث، يُعتبر bob.test@gmail.com عنوان بريد إلكتروني غير صالح ولا يمكن استخدامه.
أقترح مقارنة النسخة المبسطة، لكن يجب أن تكون حذرًا لتضمن استمرار تخزين وعرض البريد الإلكتروني إلى العنوان الذي تم تحديده في الأصل.
لا تملك موافقة المستخدم على مراسلة أي صيغة أخرى، وقد يؤدي استخدام أي عنوان غير الذي حدده هو إلى عدم استلامه للرسالة.
كمثال، لدي عنوان Gmail تم إنشاؤه في الأشهر الأولى من الخدمة. البريد الموجه إلى الاسم المستعار الأساسي يتم تجاهله فعليًا. فقط الرسائل التي تصل إلى عناوين “بلس” محددة سيتم رؤيتها.
كن حذرًا من الافتراضات أيضًا؛ فكثير من مستخدمي Gmail لا يدركون أن النقاط اختيارية. الغالبية العظمى لم يسمعوا مطلقًا عن عناوين “بلس”. إن محاولة الفرز لمنع إساءة استخدام الأخيرة قد تؤدي إلى ضحايا في الفئة الأولى.
@سام، لقد فهمت تمامًا ما يقصده جيف، وكما أنت، أنا ضد ما يقترحه (لا إهانة له، فالخلافات تحدث).
ربما هذا تفصيل مبالغ فيه، لكن تخزين عنوان البريد الإلكتروني “المُنقّح” فقط سيُزيل ما يفعله بعض المستخدمين الشرعيين عمدًا. على سبيل المثال: إذا قام مستخدم بالتسجيل (بشكل شرعي تمامًا ولمرة واحدة فقط) باستخدام bob+meta@example.com أو bob+forums@example.com، فإنه سيفقد الهدف الذي سعى لتحقيقه. المشكلة هي أنه سيستقبل البريد الإلكتروني فقط على bob@example.com، وهذا ليس ما أراد (فيمكنه مثلاً استخدام “الوسم” لوضع الرسائل المستقبَلة في مجلد معين).
أتفهم تمامًا أن مراعاة هذا الأمر سيجعل العملية أكثر تعقيدًا قليلاً. ستحتاج إلى تخزين نسختين: النسخة التي أدخلها المستخدم (لإرسال البريد الإلكتروني) والنسخة المُنقّحة. يمكنك استخدام النسخة المُنقّحة كما تستخدم عناوين البريد الإلكتروني حاليًا (لجميع الأغراض الداخلية المتعلقة بالمستخدم، وللتحقق مما إذا كان المستخدم مسجلاً بالفعل). بالإضافة إلى ذلك، لتجنب هذه المشكلة البسيطة، ستحتاج إلى تخزين ما أدخله المستخدم أيضًا (فقط لاستخدامه في إرسال البريد الإلكتروني). سيكون هذا مكافئًا لعنوان “الرد إلى” في رسائل البريد الإلكتروني.
أتمنى أن يكون ذلك مفهومًا.
تعديل: كُتب في نفس الوقت مع @ستيفن (فكرة مماثلة بشكل عام)
هذه نقطة جيدة جدًا، فهي تجعل بناء هذا الأمر أكثر تعقيدًا قليلاً.
أعتقد أنك ستقوم بإجراء الفحص فقط عند “إنشاء حساب جديد”:
هل يوجد بالفعل أي عنوان بريد إلكتروني في النظام بنفس الصيغة القياسية؟ إذا كان الجواب بنعم، نعتذر، لا يمكن إنشاء حساب جديد لك.
هناك مشكلة جانبية تتعلق بـ Google OAuth (هل ستتحقق أيضًا من البريد الإلكتروني بالصيغة القياسية)، بالإضافة إلى مشكلة الانتقال من الصيغة غير القياسية إلى الصيغة القياسية.
لا يعمل OAuth مع العناوين التي تحتوي على علامة الزائد (+) حسب علمي، أليس الأمر خارج النطاق إذن؟
أقصد بذلك أنني لا أستطيع إنشاء حساب جديد باستخدام Google، وتحديد اسم مستعار مختلف، ثم تكرار العملية.
نفس مساحة المشكلة.
أقوم بالتسجيل باستخدام sam+hi@gmail.com… ثم أضغط على زر تسجيل الدخول عبر Google، فماذا يحدث؟
حاليًا: يتم إنشاء حساب جديد.
المقترح:
الخيار أ: شاشة خطأ، لا يمكنك إنشاء هذا الحساب.
الخيار ب: يقوم المستخدم بتسجيل الدخول باستخدام sam+hi@gmail.com.
وضع القفل المقترح الأصلي: لا يمكن للمستخدم sam.test@gmail.com تسجيل الدخول عبر زر “تسجيل الدخول باستخدام Google”.
بافتراض أنه يمكنك التوصل إلى ترجمة قوية لإزالة عناوين البريد الإلكتروني المضافة والنقاط الخاطئة، يمكنك ببساطة الاحتفاظ بـ hash للبريد الإلكتروني المكرر ومقارنته بإنشاء الحساب؟
هذا هو الخيار ب، وبالتالي هناك مشكلة جانبية تتعلق بمصادقة جوجل OAuth 
كما أن مسألة الهجرة معقدة، لكن يمكن على الأرجح تجاوزها.
ومع ذلك، وبالنظر إلى نطاق المشكلة هذا في الواقع، لا أتوقع أننا سنعمل على أي تغييرات هنا في الأشهر القليلة القادمة.
كما ذُكر أعلاه، هل لا يُعد استخدام النسخة “الأساسية” فقط داخليًا مع تخزين ما أدخله المستخدم (فقط لإرسال رسائل البريد الإلكتروني) حلاً؟
يمكننا حل هذه المشكلة بسهولة، وأقدر أن العمل على اختبار وتصحيح مثل هذا المفتاح الجديد سيستغرق من يومين إلى ستة أيام، لأن هناك العديد من التفاصيل الصغيرة التي يجب الاهتمام بها.
المشكلة هنا هي أن @codinghorror لا يمكنه تبرير تخصيص هذا المبلغ من الوقت لهذه الميزة.
يمكننا تنفيذ كسر مجموعة كبيرة من تسجيلات الدخول عبر البريد الإلكتروني في يوم عمل واحد، لكنني لا أريد وجود مثل هذا الإعداد في Discourse.
لذا فأنت في موقف صعب بعض الشيء يا @Mevo… يحتاج المزيد من الأشخاص إلى تجربة هذه المشكلة والإبلاغ عنها حتى نتمكن من تبرير قضاء الوقت في حلها.
@سام، أنا أفهم ذلك.
(بالمناسبة، هذه هي المرة الأولى التي أرى فيها هذا. تم تعديل منشورك تلقائيًا: " [النظام] — تم إزالة اقتباس المنشور السابق بالكامل تلقائيًا". رائع! هذه وظيفة رائعة حقًا!)
يجب أن تكون حريصًا جدًا على عدم تخزين النسخة الأصلية أبدًا. لم يوافق المستخدم على تقديمها، وإذا تم اختراق جداول بيانات المستخدمين، فلن يتمكنوا بسهولة من تحديد الخدمة التي تسببت في اختراق بياناتهم.
لقد تعرضت فيسبوك مرارًا وتكرارًا لمشاكل كبيرة بسبب تخزين المعلومات الشخصية المتعلقة بالمستخدمين التي لم يقدموها، ولم يوافقوا على ربطها بحساباتهم.
لا أرى أي مشكلة على الإطلاق مع هذا الإعداد شخصيًا، أنا فقط أكره القيام بذلك لأن “ذلك الشخص الواحد كان لديه مشكلة في ذلك الوقت الواحد”.
نعم، هذا أمر فظيع جدًا يُقترح إضافته إلى ديسكورد. سأكون معارضًا بشدة لإضافته. بالإضافة إلى ذلك، العنونة ميزة، كانت دائمًا ميزة، وهي سهلة الاستخدام للمستخدم.
إذا كنت تتعرض للهجوم من قبل الموساد .. فعّل وضع هجوم الموساد. نحتاج فقط إلى أن يهاجم الموساد المزيد من الأشخاص، أظن ذلك؟ 
[quote=“codinghorror, post:37, topic:22627”]
لا أرى أي مشكلة على الإطلاق مع هذا الإعداد شخصيًا، أنا فقط أكره فعل ذلك لأن «ذلك الشخص واجه مشكلة في ذلك الوقت». [/quote]
أنا معارض بشدة لإضافة هذا الإعداد إلى Discourse. أنا مرتاح تمامًا لشخص ما يبني إضافة (plugin) لذلك، فهي مجرد بضعة أسطر من الكود في إضافة. إذا كنت يجب أن يكون لديك ذلك، فسأأخذ استراحة وأبني الإضافة اليوم، فقط أخبرني.
من غير المجدي إلى حد ما بنائها لأن الشخص الوحيد الذي لديه المشكلة يقول بالفعل إنه لن يستخدمها.
إعداد «كسر نظام Discourse الخاص بي» سيء جوهريًا ولا ينتمي إلى المنتج في رأيي.
أعتقد أنه لو كان المزيد من الناس يواجهون هذه المشكلة، لكان وضع قفل البريد الإلكتروني أكثر قابلية للدفاع عنه. لكن في الوقت الحالي، الأمر يتعلق بذلك الشخص الواحد في ذلك الموقع فقط.
لذا، ننتظر ونرى…
شخص واحد، في موقع واحد، لن يستخدم الميزة
هذا أكثر دقة…