هذه معلومات ممتازة. لم أرَ مشكلة CORS تحديدًا، لكنني سأبحث أكثر في هذا الشأن. إذا وجدت أي شيء، سأشاركه هنا.
بعد رؤية السكربتات، يبدو أن المشكلة مرتبطة بـ Cloudflare. هل تستخدمون Cloudflare؟ https://boards.neocron.org/cdn-cgi/apps/head/QNWX_8GN-3K7wUr6Qa73LdoD3JI.js. نحن لا نستخدم ذلك، لذا ربما لم نواجه هذه المشكلة المحددة.
شكرًا!
عند الغوص في الأمر، كنا قد قمنا بتفعيل الإعدادات -> الأمان -> سياسة أمان المحتوى.
بمجرد تعطيل ذلك، استطاع المستخدمون التسجيل. حاولنا إضافة عناوين URL الموجودة في التقرير أعلاه إلى مصادر السكريبت المعتمدة في القائمة البيضاء، لكن ذلك لم يحل المشكلة.
يبدو أن كروم قد عزز سياسة أمان المحتوى (CSP) الخاصة به. → Manifest - Content Security Policy | Chrome Extensions | Chrome for Developers
مم، أخشى أننا قمنا بتعطيل ذلك، ويجب أن يكون هناك شيء آخر لدينا يسبب هذه المشكلة
لدينا أيضًا علم CORS مفعّل، لكننا غير متأكدين مما إذا كان هذا مرتبطًا.
هذه مشكلة في سياسة محتوى المتصفح (CSP) وليست مشكلة في مشاركة الموارد عبر النطاقات (CORS).
هل هذا إعداد لمجلد فرعي؟
تعديل: بعد العودة والنظر في الأمر مرة أخرى، أدركت ما يحدث.
يمكنني تأكيد أن هذا تم حقنه بواسطة CF.
نوصي بشدة بعدم تعطيل سياسة محتوى المتصفح (CSP) على موقع إنتاجي. بدلاً من ذلك، قم بإيقاف Cloudflare إذا أمكن (لقد كانت لدينا عديدة، عديدة حالات دعم تتعلق بتأثير CF السلبي على جافا سكريبت في Discourse) أو على الأقل قم بتعطيل جميع تحسينات Cloudflare.
هذا يفتح ثغرات أمنية هائلة في موقعك. نوصي بشدة بعدم القيام بذلك. إنه نصيحة سيئة للغاية.
مرحبًا @supermathie،
نحن لا نستخدم Cloudflare، ونواجه هذه المشكلة الآن مع مستخدمين اثنين. الحل البديل الذي نقدمه لهم هو استخدام وضع التصفح المتخفي أو متصفح آخر، ولكن ربما يكون هناك مستخدمون آخرون لم يبلغوا لنا عن هذه المشكلة.
مجتمعنا يتكون في الغالب من أشخاص غير متخصصين في التكنولوجيا، لذا لا أعتقد أن لديهم إعدادات متصفح غريبة.
هل يمكنك تقديم المزيد من المعلومات حول ما يُسبب هذه المشكلة؟ ربما أستطيع البدء من هناك لإيجاد حل.
شكرًا!
نتمنى لو نحن نعرف بالضبط.
هناك حقل إدخال مخفي في شاشة “إنشاء الحساب” يتم التحقق من سلامته عند إنشاء الحساب.
إذا تم التلاعب بهذا الحقل، فإن إنشاء الحساب يفشل.
هل يمكنك الرجاء طلب من المستخدمين تعطيل الإضافات الخاصة بهم واحدة تلو الأخرى حتى يجدوا المسبب؟
لدينا أيضًا تذكرة مفتوحة مع مشروع Chrome للتحقيق في هذا السلوك.
دعني أذكرك بهذه الصورة من جهاز كمبيوتر لمستخدم غير تقني:
لا يمكنك افتراض أي شيء 
أجل، أعني أن الأمر لم يعد كما في عام 2000؛ فأمان المتصفح ومنع البرامج الضارة أصبحا أفضل الآن (أعتقد ذلك). أفاد مستخدم آخر بذلك اليوم، وسأحاول الحصول على مزيد من المعلومات منه، ونأمل أن نجد شيئًا.
شكرًا لك!
رائع. نرغب حقًا في تثبيت هذا الأمر، لذا أبلغونا بذلك.
لدي صديق يعاني من هذه المشكلة أيضًا - أحاول تعيينه كمُشرف. عندما أقوم بالتسجيل في نافذة تصفح خفية، يعمل كل شيء بشكل جيد، لكنه لا يستطيع حتى في نافذة خفية. لذا أنا متأكد من أن المشكلة ليست في تثبيت بلدي (أستخدم إضافات مع نظام Discourse، لكنها فقط الإضافات الرسمية) بل في متصفحه في مكان ما.
أعمل معه لتحديد المشكلة بدقة، لكن إذا لم تكن المشكلة متعلقة بالإضافات، فإنني أتساءل عما إذا كان هناك شيء يتعلق بإصدارات كروم لدينا - سواء كان هناك شيء يحدث في أعماق المتصفح لا أدركه، لكنني لا أستطيع الجزم بذلك بعد. أحاول حاليًا الحصول على رقم إصداره للمقارنة، لكنه من كاليفورنيا، لذا إذا كان عاقلًا، فهو نائم الآن 
حسناً، ليس من المنطقي، لكنه مستيقظ ومفيد. قام بالتحديث من الإصدار 75.0.3770.142 إلى 76.0.3808.87 (64 بت)، وهو ما لم يُسهم بمفرده في حل المشكلة في النافذة الرئيسية، لكن بعد مسح ذاكرة التخزين المؤقت وملفات تعريف الارتباط، تمكّن من التسجيل في نافذة التصفح المتخفي. وهو يستخدم إعدادات كروم نظيفة تماماً باستثناء أداة حظر الإعلانات.
تحرير: لا يمكنني الجزم بما إذا كان مسح ذاكرة التخزين المؤقت أو ملفات تعريف الارتباط سيُنجح في الإصدار 75.0.3770.142 دون القدرة على إعادة إنتاج المشكلة (ولا أستطيع ذلك)، لكنني أجد الأمر مثيراً للاهتمام أنه على الأقل بدا أنه ساعد صديقي.
مرحبًا، لقد قمت بإعداد مثيل جديد اليوم على community.boid.com وواجهت هذه الرسالة عند محاولة تسجيل حساب ثانٍ (سواء في نافذة كروم العادية أو في وضع التصفح المتخفي). تمكنت من حل المشكلة بحذف كلمات المرور المحفوظة تلقائيًا من حسابي في جوجل يدويًا وعدم استخدام أي من خيارات الملء التلقائي في نموذج التسجيل. لاحظت أن كروم كان يقترح العديد من خيارات المصادقة المختلفة للملء التلقائي من مواقع غير مرتبطة. لم أرَ هذا السلوك في مواقع أخرى، لذا أردت فقط مشاركة تجربتي.
بحسب ما أستطيع استنتاجه، يبدو أن هذا الأمر مرتبط حقًا بوظيفة الملء التلقائي في جوجل كروم.
لدي طريقة واحدة لإعادة إنتاج هذه المشكلة، لكنها غير واضحة. ستحتاج إلى نافذتي متصفح.
قم بتحميل موقعك في وضع التصفح المتخفي، ثم افتح نافذة حوار “إنشاء مستخدم جديد”.
في نافذة متصفح ثانية، سجّل الدخول كمسؤول. انتقل إلى إعدادات الموقع. فعّل خيار “الدعوة فقط”، مما يعطل التسجيل العام.
في متصفح التصفح المتخفي، حاول إكمال عملية التسجيل كمستخدم جديد عبر نافذة حوار “إنشاء مستخدم جديد” التي فتحتها سابقًا.
لن تتمكن من ذلك، لأن إنشاء المستخدمين الجدد لم يعد مسموحًا به، لذا ستظهر لك.. صديقنا القديم..
على الأقل لدينا طريقة إعادة إنتاج هذه المشكلة، رغم أنها.. مجنونة. 
لم أتمكن أبدًا من إعادة إنتاج هذه المشكلة بأي طريقة أخرى، ولم يتمكن أي شخص في هذا الموضوع من تقديم مجموعة خطوات لإعادة إنتاج المشكلة على نسخة افتراضية من متصفح Chrome دون إضافات. إذا تمكنت من ذلك، يرجى التكرم بتقديم خطوات إعادة الإنتاج هذه..
لقد قمت بإعادة إنتاج هذا الخطأ على try.discourse.org:
حسنًا، ممتاز، هذه خطوة تكرارية يمكننا العمل عليها، شكرًا لك.
ومع ذلك، تجدر الإشارة إلى أن الأمر لا يزال يتطلب إجراءً يدويًا من المستخدم — انقر بزر الماوس الأيمن في حقل كلمة المرور عند إنشاء حساب جديد / التسجيل واضغط على “اقتراح”. يجب أن أقوم بتحديث الصفحة عبر f5 قبل بدء حوار التسجيل لجعل هذا الخيار يظهر بشكل موثوق، لكنه يظهر بعد ذلك.
الآن بعد أن أصبح لدينا نوع من خطوات التكرار @sam، ربما يمكننا تخصيص المهمة؟
لدينا آليتان تعملان معًا لمنع الروبوتات من إنشاء حسابات بشكل عشوائي.
نتظاهر بوجود حقل “تأكيد كلمة المرور” وهو في الواقع “خدعة”؛ نتوقع أن يحتوي على قيمة محددة جدًا. إنه حقل إدخال لا يتم عرضه على الشاشة، بل موجود داخل div مخفي.
لدينا سلسلة تحدي نتوقع من جافا سكريبت معالجتها وإعادة إرسالها.
إذا لم تتحقق أي من الحالتين (1) أو (2) بشكل صحيح، فإننا نعتبر الطلب مشبوهًا ولا نقوم بتسجيل حساب.
ما يفعله مدير كلمات مرور كروم هو “ملء” كلمة المرور في حقل new-account-confirm:
{{input type="password" value=accountPasswordConfirm id="new-account-confirmation" autocomplete="new-password"}}
هذا حقل الإدخال مخفي ولا يتم عرضه على الشاشة.
لدينا بديلان هنا.
إزالة هذه الحماية والقبول بحقيقة أن مديري كلمات المرور يخطئون في هذا الأمر. فهم لا يتحققون من أن حقل “تأكيد كلمة المرور” مرئي فعليًا قبل ملئه.
طلب من فريق كروم التوقف عن القيام بذلك، فملء المعلومات في حقول الإدخال غير المرئية ليس أمرًا مقبولًا. (لقد قمت بذلك)
لا أعرف… أعتقد أننا يمكننا المضي قدمًا في الخيار (1)، فهو تغيير سهل. يمكنني إزالة الحماية وجعل عميل جافا سكريبت يحسب تجزئة بأسلوب البيتكوين لإثبات أنه يعمل. على سبيل المثال، أعطيه سلسلة وأطلب منه إرفاق أرقام بها حتى تنتهي تجزئة MD5 بـ 00 على الأقل؛ سيكون هذا عقابًا للروبوتات ورخيصًا جدًا للتحقق منه على الخادم.
جعل الروبوتات تحسب تجزئات MD5 بشكل أعمى، أعتقد، هو أحد الطرق لجعلها تدفع الفواتير حرفيًا وتمول تقاعدي في جزر البهاما.
هل من الممكن تعطيل هذه الآلية بالكامل وتمكين نظام Google CAPTCHA القديم؟ أعتقد أن هذا سيحافظ على الأمان وفي الوقت نفسه يسمح لمزيد من المستخدمين بالتسجيل.
أو يمكننا انتظار التصحيح السريع (hotfix) الخاص بكم. أي خيار يبدو الأفضل لديكم؟ سنطلق دفعة كبيرة من شركائنا على منتدانا في بداية الأسبوع القادم.
لقد أنشأت للتو حسابًا جديدًا، دون أي برامج مكافحة البريد العشوائي أو التجسس أو أي برامج أخرى على المتصفح، وواجهت نفس المشكلة. تم حلها باستخدام طريقة ‘تسجيل الدخول عبر Google’ وعملت بعد ذلك.
