Freecodecamp: الزر Code Locked / Unlocked هو تجربة مستخدم مربكة للمبتدئين

tchaffee شكرًا على التقرير ، وإغلاق هذا لصالح https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

raisedadead العدد # 16250 يصف مشكلة مختلفة. ما يقلقني هو: كيف يعرف المبتدئ ما إذا كان تنفيذ التعليمات البرمجية آمنًا أم لا؟ تجربة المستخدم سيئة لأنه لا توجد طريقة يمتلك المبتدئ المعلومات اللازمة لاتخاذ هذا القرار.

حسنًا ... هذا يعني أننا سنحتاج إلى تحدي خطوة ، من أجل الصعود إلى الطائرة.

QuincyLarson هل لديك أي شيء في الاعتبار؟

أو ربما إعادة النظر في الطريقة التي قدمنا ​​بها في البداية لهذا المطلب؟ هل هناك أي خطر في تشغيل التعليمات البرمجية من التخزين المحلي؟ أتلقى التحذير حتى في حالة عدم وجود رمز في URI ، ويبدو هذا كتحذير غير ضروري لأن هذا مجرد عملي المحفوظ.

لا أعرف خلفية حالة الاستخدام هذه ، لكنني أعتقد أن الكود في URI مخصص للمشاركة؟ وأعتقد أن هذا هو الخطر الأمني ​​الحقيقي؟

ربما يمكننا التفكير في حل آخر لمشاركة التعليمات البرمجية بدلاً من مطالبة المبرمجين المبتدئين بتحديد ما إذا كان تنفيذ الكود آمنًا. أعتقد أنه سيكون من المفيد أن نفهم أولاً ما يقدمه الحل الحالي وما هي المتطلبات التي أدت إلى حلنا الحالي. أو قد يكون الأمر أن مشاركة الكود عبر URI هي مجرد فكرة سيئة في كل مكان.

أو ربما إعادة النظر في الطريقة التي قدمنا ​​بها في البداية لهذا المطلب؟ هل هناك أي خطر في تشغيل التعليمات البرمجية من التخزين المحلي؟ أتلقى التحذير حتى في حالة عدم وجود رمز في URI ، ويبدو هذا كتحذير غير ضروري لأن هذا مجرد عملي المحفوظ.

الشرط راسخ. كان علينا معالجة العديد من مشكلات XSS في الإنتاج. احتاج أحدثها إلى حظر المشاركة تمامًا. هناك عدة نواقل حول كيفية تنفيذ رمز غير آمن.

يمكن للمستخدم على سبيل المثال نسخ رمز اللصق من أي مكان ، وقد يؤدي ذلك عمليًا إلى مثل هذه المشكلات. لا يمنع الإصلاح الحالي مثل هذا المتجه ، ولكنه يحد من الناحية الفنية أي تنفيذ مع التحذير. تعد تجربة المستخدم من حولها مصدر قلق بالطبع ، وبالتالي فهي تحتاج إلى مسار تعليمي.

ربما يمكننا التفكير في حل آخر لمشاركة التعليمات البرمجية بدلاً من مطالبة المبرمجين المبتدئين بتحديد ما إذا كان تنفيذ الكود آمنًا.

طبعا، لم لا. لا تتردد في إلقاء نظرة ونود أن يكون لدينا حل يزيد من الإصلاح الحالي وهو أساسًا كتلة مستوى الأشعة تحت الحمراء للتنفيذ. بالطبع ، إذا كنت مهتمًا ، فيمكننا استخدام المساعدة في العلاقات العامة.

أو قد يكون الأمر أن مشاركة الكود عبر URI هي مجرد فكرة سيئة في كل مكان.

لدينا صناديق في المخطط ، لكن هذا لن يحدث قريبًا ، حيث أننا نجهز البنية التحتية من حوله. راجع https://github.com/freeCodeCamp/freeCodeCamp/issues/11263

كان الأمر كذلك ، عندما كان المستخدم هو النموذج الوحيد ، وكان علينا أن نحافظ على وزن قاعدة البيانات لدينا ، فإننا نخطط لجعلها أكثر فصلًا بشكل تدريجي.

الشرط راسخ.

أي واحدة؟ أفهم أن إحضار الكود من التخزين المحلي هو أحد المتطلبات. هذا منطقي بالنسبة لي - لا ينبغي أن يفقد المعسكر الكود الذي بدأوا العمل عليه.

هل هناك متطلب آخر لتشغيل التعليمات البرمجية من URI؟ لا أعرف الكثير عن ذلك ، إنه فقط يدق جرسًا من المشكلة الأمنية التي رأيتها قبل بضعة أسابيع.

يبدو أنهما متطلبان مختلفان لهما هدفان مختلفان ، ومخاطر أمنية مختلفة؟

لا تتردد في إلقاء نظرة ونود أن يكون لدينا حل يزيد من الإصلاح الحالي وهو أساسًا كتلة مستوى الأشعة تحت الحمراء للتنفيذ.

لست خبيرًا في الأمن ، ولكن سأكون سعيدًا لمحاولة التوصل إلى شيء ما إذا كان بإمكاني فهم المتطلبات بشكل أفضل. هل يمكن لشخص ما أن يصف جميع المتطلبات بالتفصيل من منظور كامبر ، إلى جانب الثغرة الأمنية التي حاولت التغييرات الأخيرة إصلاحها؟ أيضا ، ما هي "كتلة مستوى الأشعة تحت الحمراء"؟

لدينا صناديق في المخطط.

المشكلة لا تصف هذا الحل بالتفصيل الكافي حتى أفهم ما هو. هل يمكن أن تعطيني مزيدًا من التفاصيل حول ماهية "الصناديق" وما هو الحل المتصور؟

على أي حال ، لا أريد تحويل هذا إلى شيء أكبر مما هو عليه. ربما يكون التحدي التدريجي على متن الطائرة هو الحل المناسب في الوقت الحالي. لكنني أشعر بالفضول حقًا كيف سيبدو ذلك على متن الطائرة. هل من الممكن تعليم Campers في البداية الرمز الذي يجب الوثوق به وأيها لا ينبغي الوثوق به؟ إذا كنت تفكر في شيء ما أود رؤيته لأنه ربما يكون أبسط مما أتخيله.

شكرا لفضولك حول هندسة المشروع. أود بالتأكيد الرد على جميع استفساراتك ، لكنني أخشى أن شرح كل شيء في هذا الموضوع لن يكون كافيًا أو مبررًا.

أتفهم أنك ربما تبدأ في هذا الأمر ، لذا سأحاول أن أكون واضحًا قدر الإمكان ، ولكن يرجى ترك استفساراتك إذا كان هناك شيء غير واضح.

سآخذ هذا الاستعلام وسأحاول أن أقدم لك السياق:

هل يمكن لشخص ما أن يصف جميع المتطلبات بالتفصيل من منظور كامبر ، إلى جانب الثغرة الأمنية التي حاولت التغييرات الأخيرة إصلاحها؟ أيضا ، ما هي "كتلة مستوى الأشعة تحت الحمراء"؟

• أولاً ، هناك اختلاف كبير حول كيفية تقييم الكود وتنفيذها في الإنتاج (freeCodeCamp.org) والتشغيل المرحلي (beta.freeCodeCamp.org) من جانب العميل. مناقشة هذا الأمر خارج النطاق قليلاً ، لذلك أنصح بإلقاء نظرة على الكود. ولكن فقط لإعطائك نظرة ثاقبة للعملية ، فهي تأخذ الكود في المحرر وتنفيذه في سياق المتصفح (باستخدام EVAL ، وإحالة الكود ) وإن كان ذلك بطرق مختلفة تمامًا.

• الآن ، تعال إلى منظور العربة. تخيل كل السيناريوهات التي ستفعلها كمخيم:

  • يمكنك البدء في تحرير الكود في محررك.
  • يمكنك لصق رمز في المحرر الخاص بك
  • يمكنك التعديل جزئيًا والانتقال إلى تحدٍ آخر والعودة.
  • يمكنك زيارة الملف الشخصي لشخص ما ، أو النقر فوق ارتباط عرض الحل ، أو النقر فوق ارتباط في المنتدى ، وما إلى ذلك ، أو ما يُعرف باسم URI.
  • يمكنك ...
    أو أي مزيج مما سبق ممكن أيضًا.
• في جميع الحالات ، تصل إلى نفس المحرر حيث سيتم تحليل الكود وتقييمه.
• يمكن أن يكون هذا التحليل من التعليمات البرمجية المكتوبة أو التخزين المحلي أو URI.

• في جميع الحالات ، سيتم إجراء بعض فحوصات الأمان ، على سبيل المثال حماية الحلقة اللانهائية ، و / أو إزالة الشريط و / أو استبدال العلامات أثناء تشفير الحل قبل الإرسال إلى DB ، وما إلى ذلك.

• مع لا. من المجموعات ، من المعقد حقًا التعامل مع نواقل هجوم متعددة.

• هذا مجرد أمان.

• ثم يأتي سير العمل:

  • هناك حاجة إلى التخزين المحلي للحصول على طريقة ما ، من أجل "الحفظ التلقائي" للعمل ، دون التأثير على قاعدة البيانات.
  • هذا صحيح ، لأن الحلول المقدمة والتي تم تمريرها فقط يجب أن تذهب إلى قاعدة البيانات.
  • يجب أن تكون الحلول الجزئية (المحررة أو الملصقة) ، أي (تم الإرسال + عدم النجاح أو العمل) موجودة في التخزين المحلي.
  • بالإضافة إلى ذلك ، يجب ترميز / فك تشفير المعاملات (مشاركة / عرض URI) بين DB والتخزين المحلي لأسباب ذكرتها سابقًا.

هنا من خلال المعاملات أعني الوصول إلى حالة يكون فيها المحرر لديه رمز ، وهذا موجود بسبب قيام المستخدم بالنقر فوق ارتباط مشترك من ملفه الشخصي أو في أي مكان آخر.

أولوية حلول التحميل للتقييم هي Editor > Local Storage > URI/DB

إذا قارنت بين السيناريوهات وسير العمل ، فمن المحتمل أن تحصل على فكرة أكثر عن مدى تعقيد المنطق ، مع الحفاظ على متجهات الهجوم في وضع حرج.

ومن ثم ، فإن الفحص الشامل هو عدم تشغيل أي شيء في المحرر في جميع التحديات ، دون موافقة صريحة ، عبر طريقة Code Unlock. هذه هي كتلة مستوى الأشعة تحت الحمراء التي أتناولها. لن يذهب هذا إلى أي مكان ، حتى تكون هناك طريقة آمنة لتنفيذ جميع التعليمات البرمجية في بيئة معزولة في المتصفح.

أوافق على أن هذا قد يكون سيئًا لـ UX. ومن ثم يمكن أن يكون الإعداد وسيلة لإظهار سبب الحاجة إلى ذلك ، دون الدخول في الكثير من التعقيد ، وإخافة المستخدمين الجدد.

أخيرًا ، ستكون الحاويات شيئًا مشابهًا مثل الروابط القصيرة ، كما ترى في مكان آخر. على سبيل المثال: codepen ، jsbin إلخ. ملاحظة: أقوم بتبسيط الفكرة هنا.

يمكن أن تساعدنا هذه في تخزين / عرض الكود بأمان دون زيادة الأولوية الحالية.

وبالتالي،

إصلاح UX الحقيقي هو ببساطة شرح التحذير ، في تحدٍ داخلي.

من فضلك ، لاحظ أنه قد يكون لدي أشياء مبسطة هنا. إذا كان لديك اهتمام ، فإنني أوصي بالتحقق من الكود. إذا علقت ، فنحن منفتحون للتعامل مع أي تفاهم على هذه الجبهة. لذا يرجى إسقاط أي استفسار هنا.

مرة أخرى فقط لإعادة التكرار:

1. نعم ، هناك العديد من المتطلبات ، ولكن جميعها لها نفس نقطة الدخول للتنفيذ / التقييم والعرض. ومن ثم هناك حاجة للقفل / فتح القفل. تؤدي جميعها إلى نفس المخاطر الأمنية.
2. هذا اعتبارًا من الآن ، فحص شامل لجميع المسارات الواردة من الكود إلى آلية التقييم.
3. نحتاج بالتأكيد إلى معالجة تجربة المستخدم باعتبارها شكلاً من أشكال التعلم:

هل من الممكن تعليم Campers في البداية الرمز الذي يجب الوثوق به وأيها لا ينبغي الوثوق به؟ إذا كنت تفكر في شيء ما أود رؤيته لأنه ربما يكون أبسط مما أتخيله.

1. الكود ، الذي تم إنشاؤه لحل التحدي (إما عن طريق الكتابة يدويًا ، أو النسخ / اللصق من أي محرر آخر) موثوق به.

2. الرمز ، الذي تم إنشاؤه بواسطة شخص آخر (بما في ذلك الروابط من ملفه الشخصي) ، غير موثوق به ، ويجب مراجعته مرة واحدة. يمكنهم ببساطة التحقق من أن الحل في المحرر يبدو منطقيًا بالنسبة لهم. لأنه إذا قاموا بإلغاء قفل أي رمز عشوائي ، دون فهم ما هو عليه ، فقد يخاطرون ببعض حراس الأمان المحتملين.

نحتاج فقط إلى إعداد كلام حول النقطتين المذكورتين أعلاه ، وإنشاء تحدٍ داخلي.

أتمنى أن يعطيك هذا بعض السياق؟ إذا لم يكن كذلك ، فلا تتردد في إضافة المزيد من الاستفسارات. مساهمة سعيدة!

raisedadead شرحك التفصيلي يساعد كثيرًا. لدي المزيد من الأسئلة / الملاحظات التي آمل أن تقودنا إلى أفضل تنفيذ على المدى القصير والطويل.

هو أخذ الكود في المحرر وتنفيذه في سياق المتصفح (باستخدام EVAL

هذه هي نقطة الضعف التي تخلق المشاكل الأمنية. أنا لا أقول أنه يمكن تجنبه ، ولكن فقط أشير إلى أنه شيء يجب تبادل الأفكار حوله في حالة توصل شخص ما إلى طريقة أكثر أمانًا لتوفير نفس الوظيفة. ربما ليس لأنه في نهاية اليوم عليك تنفيذ التعليمات البرمجية. ولكن دعونا نتفتح أذهاننا حيال ذلك. سألتزم بالسؤال.

لنلقِ نظرة أقرب قليلاً على الوظائف والمتطلبات:

يجب أن تكون الحلول الجزئية (المحررة أو الملصقة) ، أي (تم الإرسال + عدم النجاح أو العمل) موجودة في التخزين المحلي.

الكود ، الذي تم إنشاؤه لحل التحدي (إما عن طريق الكتابة يدويًا ، أو النسخ / اللصق من أي محرر آخر) موثوق به.

مما سبق يبدو لي أنه يجب الوثوق في التعليمات البرمجية من التخزين المحلي ولكن لا يتم الوثوق بها. هل هناك طريقة للتمييز بين الكود الذي يأتي من URI (بالتأكيد غير موثوق به) والرمز الذي كتبته سابقًا والذي يأتي من التخزين المحلي الخاص بي؟ هذا التغيير الصغير وحده من شأنه أن يجعل UX أفضل بكثير. خاصة وأننا قد نجعل الرسالة أكثر تحديدًا: "لقد استخدمت URI مع رمز بداخلها ، هل تثق في الكود؟"

إذا كان من الممكن اكتشاف الكود الذي يأتي من URI وعدم الوثوق به فقط ، فأعتقد أنه يمكن أن يتناسب جيدًا مع سير العمل والوظائف الحالية. إذا جاء الرمز من URI ، فلن نقوم بحفظ أي رمز في التخزين المحلي إلا بعد أن يضغط المستخدم على "Code Locked / Unlock؟" زر. بعد ذلك أشار المستخدم إلى أنه يثق في الكود ، بحيث يمكن وضعه بأمان في التخزين المحلي ثم تنفيذه دون سابق إنذار في المستقبل عند عودته.

على المدى الطويل ، أتساءل بالتأكيد عما إذا كان إرسال التعليمات البرمجية في URI مجرد فكرة سيئة بشكل عام ، وإذا كان بإمكاننا إيجاد طريقة أفضل لمشاركة الحلول والرموز. لكنني سأكرر هذا السؤال على المدى الطويل لأنه يتطلب بعض التغييرات الكبيرة في الطريقة التي تتم بها الأمور حاليًا.

يمكنهم ببساطة التحقق من أن الحل في المحرر يبدو منطقيًا بالنسبة لهم.

هذا جعلني مقتنعًا بأن عملية الالتحاق يمكن أن تكون بسيطة بما يكفي لتكون فعالة. "إذا لم تتعرف على الشفرة أو تفهمها في المحرر ، فلا تثق بها."

ولكن إذا كان من الممكن التمييز بين الكود الذي يأتي من URI والرمز في التخزين المحلي ، فأنا أتساءل حتى عما إذا كان الإعداد ضروريًا ، لأن التحذير فقط في هذه الحالة لا يبدو لي تجربة مستخدم سيئة. "لقد استخدمت للتو رمزًا من URI ، يرجى التأكد من أن الشفرة الموجودة في المحرر منطقية قبل إلغاء تأمينها."

raisedadead لا أعرف ما إذا كنت قد قابلت tchaffee من قبل لكنه مساهم غزير في freeCodeCamp. إنه مطور متمرس ، وأحد الأشخاص الرئيسيين وراء مشاريعنا الجديدة القابلة للاختبار .

حسنًا ... هذا يعني أننا سنحتاج إلى تحدي خطوة ، من أجل الصعود إلى الطائرة.

لا نريد إضافة المزيد من تحديات الخطوات. إذا كان هناك أي شيء ، فنحن نريد التخلص من تحديات الخطوة التي لدينا.

هذا لأن الناس لا يقرؤون .

أحد الأسباب التي تجعلنا نحاول جعل نص درس التحدي مقتضبًا قدر الإمكان هو أنه كلما زاد النص ، قل احتمال تحلي المستخدم بالصبر لقراءته.

tchaffee على حق - نحن بحاجة إلى تحسين

أقترح أن نقوم بقفل الكود فقط إذا وصلوا إلى التحدي من خلال النقر على عنوان URL يحتوي على رمز شخص آخر. خلافًا لذلك ، يجب ألا نحذرهم من تشغيل الكود.

JSBin ، CodePen ، لا أعتقد أن أيًا من هذه المواقع يحذر الأشخاص من تشغيل كود الآخرين مثل هذا. أعتقد أنه يمكننا تحذيرهم ، ولكن فقط في المواقف التي يُرجح أنهم يقومون فيها بتشغيل كود غير خاص بهم. خلاف ذلك ، فإن النقر فوق هذا الزر أمر مزعج حقًا وسيزيد من التناقص.

يمكنك البدء في تحرير الكود في محررك.

لا حاجة لقفل.

يمكنك لصق رمز في المحرر الخاص بك

لا حاجة لقفل (يجب أن نفترض أنك قرأت بالفعل الكود الذي تلصق فيه)

يمكنك التعديل جزئيًا والانتقال إلى تحدٍ آخر والعودة.

لا حاجة لقفل

يمكنك زيارة الملف الشخصي لشخص ما ، أو النقر فوق ارتباط عرض الحل ، أو النقر فوق ارتباط في المنتدى ، وما إلى ذلك.

هذا هو الموقف الوحيد عندما تكون هناك حاجة للقفل imho.

أيضًا ، نحتاج إلى إعادة صياغة هذا إلى حيث لا نحتاج إلى رسالة تحوم. لا نستخدم الرسائل أثناء التمرير في أي مكان آخر في قاعدة التعليمات البرمجية ، ولا ينبغي لنا ذلك لأنها لا تعمل على الهاتف المحمول. يجب كتابة كل النص الذي نريد استخدامه على الزر نفسه.

يجب كتابة كل النص الذي نريد استخدامه على الزر نفسه.

أعتقد أن نص الزر الحالي يمكن أن يعمل إذا قمت أيضًا بعرض ارتباط أسفل الزر بمحاذاة سطور "لماذا تم قفل الرمز الخاص بي؟". مجرد اقتراح.

أيضًا ، يمكنني محاولة تناول هذه المشكلة إذا لم يكن لدى أي شخص آخر الوقت الكافي لذلك. سأحتاج إلى بعض المساعدة مع شخص يوجهني إلى جميع التعليمات البرمجية ذات الصلة. ولكن إذا كان هناك شخص أكثر تأهيلًا وراغبة ، فدعهم بالتأكيد يأخذون هذه المشكلة.

tchaffee سيكون ذلك رائعا!

بدلاً من أن يكون لدينا رابط ، نحتاج فقط إلى اكتشاف طريقة موجزة لشرحها بأقل عدد ممكن من الكلمات ، حتى لو كان الزر بطول سطرين. "أنا أثق في هذا الرمز. قم بإلغاء قفله."

مرة أخرى ، نريد فقط أن يظهر هذا الزر عندما لا يكون الرمز هو الكارافان.

QuincyLarson نعم ، بينما أود أيضًا تجنب التدفق الداخلي ، وتحديث الملصق فقط.

لا يزال هذا يترك حقيقة أنه وفقًا للمنطق الحالي من جانب العميل ، يجب تنفيذ حظر رمز غير المستخدم فقط.

أعني بهذا المنطق الخاص بالزر "I trust this code. Unlock it." لتتمكن من عرضه فقط عندما يأتي الرمز من URI ، وما إلى ذلك ، لا يزال يتعين تنفيذه.

سأضيف PR لتحديث الملصق وإغلاق المشكلة الأخرى https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

لا يزال هذا يترك حقيقة أنه وفقًا للمنطق الحالي من جانب العميل ، يجب تنفيذ حظر رمز غير المستخدم فقط.

لست متأكدًا من أين يترك هذا عرضي لتنفيذ السلوك الجديد. يمكنني محاولة تنفيذ رمز الحظر فقط لغير المستخدم ، ولكن يبدو أن الوقت الحالي ليس هو الوقت المناسب؟ هل يمكن لأحد أن يوضح؟

سأضطر إلى التحقق مرة أخرى ، من كيفية عمل هذا لإعطائك إرشادات محددة للغاية حول ما يجب القيام به ، وفي الوقت نفسه BerkeleyTrue على مدخلاته.

أعني بهذا منطق الزر "أنا أثق في هذا الرمز. افتحه." لتكون قادرًا على العرض فقط عندما يأتي الرمز من URI ، وما إلى ذلك ، لا يزال يلزم تنفيذه.

raisedadead نعم - أتفق معك. يعد القيام بذلك أمرًا مهمًا وسيوفر لآلاف المعسكر سلامتهم العقلية.

لقد قمت بنقل هذا إلى "المسار الحرج" في الإصدار التجريبي الخاص بنا كانبان: https://github.com/freeCodeCamp/freecodecamp/projects/1؟fullscreen=true

ما زلت سعيدًا بتجربة هذا إذا كان بإمكان أحدهم توجيهي إلى أجزاء الكود المعني. أنا متأكد من أنني قد أجدها بنفسي ، ولكن إذا كان شخص ما على دراية بالرمز ، فسيوفر بعض الوقت. هل يمكن لأي شخص إخباري ما هي حالة هذا؟

tchaffee شكرا على صبرك.

Bouncey هل تعرف أين يكمن هذا المنطق في قاعدة الشفرة؟ هل يمكنك توجيه tchaffee في الاتجاه الصحيح؟

تضمين التغريدة

يمكنك التحقق من URI باستخدام pathnameSelector

يمكنك استخدامه عن طريق تمريره إلى طريقة mapStatetoProps لمكون SidePanel ، يمكنك بعد ذلك التفاعل مع ToolPanel من هناك

أتمنى أن يساعد هذا 👍

بدأت ألقي نظرة على هذا ولدي سؤال. هل يمكن لأحد أن يعطيني مثالاً على كيفية القيام بما يلي:

يمكنك زيارة الملف الشخصي لشخص ما ، أو النقر فوق ارتباط عرض الحل ، أو النقر فوق ارتباط في المنتدى ، وما إلى ذلك ، أو ما يُعرف باسم URI.

على موقع بيتا ، أرى فقط نافذة منبثقة للحلول ولا يوجد URI يقوم بتحميل الكود. لذا يبدو أن هذا قد تغير في بيتا؟ هل هناك أي أماكن أخرى يمكن تحميل التعليمات البرمجية من URI؟ هل يمكن لأحد أن يوجهني إلى مثال URI؟

شكر!

tchaffee هذا صحيح ، حالة الاستخدام هذه لم تعد صالحة:

يمكنك زيارة الملف الشخصي لشخص ما ، أو النقر فوق ارتباط عرض الحل ، أو النقر فوق ارتباط في المنتدى ، وما إلى ذلك ، أو ما يُعرف باسم URI.

لقد تم بالفعل استبداله بوحدة نمطية الآن ، مما يجعله أكثر أمانًا من الاضطرار إلى تحليل URI في المحرر. لذلك أعتقد أن التحميل من URI لم يعد في الصورة.

الآن ، هذا يقودنا إلى Code Locking / Unlocking. هذا هو الوقت الذي يجب أن يظهر فيه الزر.

فيما يلي بعض السيناريوهات التي يمكنني التفكير فيها:

1. يمكن للمخيمين إعادة زيارة التحدي ، من الخريطة.
2. في مثل هذه الحالة ، سيتم تحميل الرمز في المحرر من التخزين المحلي ، إذا كان متاحًا.
3. أو ، سيتم جلبه من الواجهة الخلفية ، وإضافته إلى التخزين المحلي ثم وضعه في المحرر.

الآن ، في عالم مثالي سيكون الأمر كذلك ، أن هذا الرمز مملوك من قبل العربة.

ولكن ، مهما كانت الاحتمالات ، فإن الكود هو الذي يتم تحميله على المحرر ويتم تنفيذه. هذا يترك لنا مكانًا حيث يمكن تنفيذ التعليمات البرمجية غير الآمنة؟ على الأقل هذا هو ناقل يمكنني رؤيته.

لذلك ، علينا التأكد من أن المخيم على دراية بما سيتم تنفيذه ، ويتم ذلك بموافقة صريحة.

لذلك ، لا يزال جزء حظر الكود من التخزين المحلي أو الواجهة الخلفية (رمز غير مستخدم) ، كما أعتقد. ولكن ، وجود الزر لها بعض ما أعتقد أنه غير ضروري.

يجب أن يكون من الممكن قفل الكود لغير المستخدم ، أي لا يتم تنفيذه ، إذا كان غير رمز البذرة الأصلي أو شيء ما تم كتابته بواسطة الكود (رمز المستخدم).

تضمين التغريدة BounceyBerkeleyTrue هل أنا محق في هذا الرأي؟

أوه ، نعم والشيء الوحيد أن نلاحظ أن تحليل URI لا يزال متاحًا ، ولا يذهب إلى أي مكان لأن محرر التحدي لا يعرف حقيقة أن لدينا طريقة عرض ملف تعريف تفاعل مع مشروطة للحلول.

سأحاول مشاركة مثال URI إذا حصلت على بعض الوقت.

ولكن ، مهما كانت الاحتمالات ، فإن الكود هو الذي يتم تحميله على المحرر ويتم تنفيذه. هذا يترك لنا مكانًا حيث يمكن تنفيذ التعليمات البرمجية غير الآمنة؟

أود أن أقول أنه لا. إذا قام أحد الكارافبات بنسخ / لصق رمز من مكان آخر ، فيجب عليه التأكد من أنهم يفهمون الكود وأن الكود آمن. يكافئ هذا النهج أيضًا الصدق ويعاقب الغش - إذا كنت لا تفهم ما يفعله الرمز المنسوخ ، فلا يجب أن تلصقه أبدًا. من الواضح أنك لا تستطيع كتابتها بنفسك إذا لم تفهمها ، لذا فإن أي ضرر تسببه هو نتيجة غش حقيقي.

هناك طريقتان "صادقتان" فقط لإدخال التعليمات البرمجية إلى المحرر في المرة الأولى ؟

1. انسخ / الصق شيئًا تفهمه وربما كتبته بنفسك.
2. اكتب الرمز بنفسك.

عند أي نقطة يتم حفظه في التخزين المحلي أو الواجهة الخلفية؟

أي كود يأتي من التخزين المحلي أو الخلفية ويتم وضعه في المحرر ، يجب أولاً أن يأتي من إحدى الطرق المذكورة أعلاه. لذلك يمكن دائمًا التعامل مع الكود من التخزين المحلي أو الواجهة الخلفية على أنه آمن.

يجب أن يكون من الممكن قفل الكود لغير المستخدم ، أي لا يتم تنفيذه ، إذا كان غير رمز البذرة الأصلي أو شيء ما تم كتابته بواسطة الكود (رمز المستخدم).

في ما سبق ، ليست هناك حاجة IMO هذا.

لا يزال تحليل URI متاحًا ، ولا يذهب إلى أي مكان لأن محرر التحدي لا يعرف حقيقة أن لدينا طريقة عرض ملف تعريف تفاعل مع مشروطة للحلول.

هذا هو المتجه الوحيد غير الآمن الذي يمكنني التفكير فيه. إذا كان بإمكانك إعطائي مثالاً ، فسأحاول اكتشاف ذلك وإظهار زر "فتح" في هذه الحالة فقط.

بالطبع إذا فاتني شيء ، من فضلك صححني.

نعم ، النقطتان الأوليان اللتان ذكرتهما هما أقل السيناريوهات لقفل الرمز ، وهو ما أوافق عليه. وبينما يجب أن نحجبه بشكل مثالي. هذا شيء مكلف.

عند أي نقطة يتم حفظه في التخزين المحلي أو الواجهة الخلفية؟

يتم حفظه بمجرد توفر أي رمز في المحرر. لذلك يتم احتساب النسخ واللصق والكتابة في ذلك.

هذا هو المتجه الوحيد غير الآمن الذي يمكنني التفكير فيه. إذا كان بإمكانك إعطائي مثالاً ، فسأحاول اكتشاف ذلك وإظهار زر "فتح" في هذه الحالة فقط.

هذه هي الحالة الوحيدة التي يجب التعامل معها. ومرة أخرى هذه ليست أولوية في الوقت الحالي. ستقول حالة الاستخدام لهذا عندما يكون لدينا الحلول القادمة من تكامل جهة خارجية لتطبيق الويب الخاص بنا عبر URI.

لذا ، فإن الفحص في مكانه كافٍ ، وكما اكتشفت بشكل صحيح ، يجب علينا منع هذا بذكاء فقط.

سوف أشارك مثال URI في أسرع وقت ممكن. (ستيوارت إذا كنت قادرًا ، فلا تتردد في التغلب على هذا رغم ذلك)

raisedadead شكرا للتوضيح. أوافق على أنه يجب علينا قفل الزر فقط عندما يقوم المستخدم بتحميل التحدي لأول مرة وهناك معلمات رمز في عنوان URL. في جميع المواقف الأخرى ، لا ينبغي لنا قفل الكود ، ويجب فقط تشغيله عندما ينقر المستخدم على الزر أو يضغط على ctrl + enter في المرة الأولى.

بمجرد أن يعطيني شخص ما مثالاً على رمز في عنوان URL ، يمكنني البدء في العمل على هذا.

tchaffee نقوم باختبار الكود في URI هنا .

يمكنك إرسال إجراء لقفل الكود في كتلة if مثل هذا

return Observable.of(
  makeToast({
    message: 'I found code in the URI. Loading now.'
  }),
  storedCodeFound(challenge, finalFiles),
  // lockTheCodeAction()
);

هذا من شأنه أن يبقيك منتجًا حتى نتمكن من الحصول على رمز URI للعب به

tchaffee هنا مثال URL: http: // localhost : 3000 / Challenges / Check٪ 20for٪ 20Palindromes؟ solution = function٪ 20palindrome (str)٪ 20٪ 7B٪ 0A٪ 20٪ 20str٪ 20٪ 3D٪ 20str.toLowerCase (). الاستبدال (٪ 2F٪ 5B٪ 5CW_٪ 5D٪ 2Fg٪ 2C٪ 20٪ 27٪ 27)٪ 3B٪ 0A٪ 20٪ 20 for (var٪ 20i٪ 20٪ 3D٪ 200٪ 2C٪ 20len٪ 20٪ 3D ٪ 20str.length٪ 20-٪ 201٪ 3B٪ 20i٪ 20٪ 3C٪ 20len٪ 2F2٪ 3B٪ 20i٪ 2B٪ 2B)٪ 20٪ 7B٪ 0A٪ 20٪ 20٪ 20٪ 20if (str٪ 5Bi٪ 5D ٪ 20!٪ 3D٪ 3D٪ 20str٪ 5Blen-i٪ 5D)٪ 20٪ 7B٪ 0A٪ 20٪ 20٪ 20٪ 20٪ 20٪ 20return٪ 20false٪ 3B٪ 0A٪ 20٪ 20٪ 20٪ 20٪ 7D ٪ 0A٪ 20٪ 20٪ 7D٪ 0A٪ 20٪ 20 عودة٪ 20true٪ 3B٪ 0A٪ 7D

سيؤدي ذلك إلى عنوان URL http: // localhost : 3000 / updates / check-for-palindromes وتعبئة الكود التالي:

function palindrome(str) {
  str = str.toLowerCase().replace(/[\W_]/g, '');
  for(var i = 0, len = str.length - 1; i < len/2; i++) {
    if(str[i] !== str[len-i]) {
      return false;
    }
  }
  return true;
}

QuincyLarson شكرا لك. كنت مترددًا في بدء العمل على هذا دون أن أتمكن من اختبار عملي. يمكنني تخصيص بعض الوقت للنظر في هذا قريبًا.

تضمين التغريدة يسرني أني استطعت المساعدة. يرجى إعلامي إذا كان بإمكاني فعل أي شيء آخر لإبقائك غير محظور :)

عنوان URL الفعلي الذي أحتاج إلى استخدامه هو http: // localhost : 3000 / en / updates / javascript-algorithms-and-data-architecture-projects / palindrome-checker؟ solution = function٪ 20palindrome (str)٪ 20٪ 7B٪ 0A ٪ 20٪ 20str٪ 20٪ 3D٪ 20str.toLowerCase (). استبدل (٪ 2F٪ 5B٪ 5CW_٪ 5D٪ 2Fg٪ 2C٪ 20٪ 27٪ 27)٪ 3B٪ 0A٪ 20٪ 20for (var٪ 20i٪ 20 ٪ 3D٪ 200٪ 2C٪ 20len٪ 20٪ 3D٪ 20str.length٪ 20-٪ 201٪ 3B٪ 20i٪ 20٪ 3C٪ 20len٪ 2F2٪ 3B٪ 20i٪ 2B٪ 2B)٪ 20٪ 7B٪ 0A٪ 20 ٪ 20٪ 20٪ 20if (str٪ 5Bi٪ 5D٪ 20!٪ 3D٪ 3D٪ 20str٪ 5Blen-i٪ 5D)٪ 20٪ 7B٪ 0A٪ 20٪ 20٪ 20٪ 20٪ 20return٪ 20false٪ 3B ٪ 0A٪ 20٪ 20٪ 20٪ 20٪ 7D٪ 0A٪ 20٪ 20٪ 7D٪ 0A٪ 20٪ 20return٪ 20true٪ 3B٪ 0A٪ 7D

فقط ضع هذا هنا للتوثيق. لا حاجة للتعليق.

Bouncey هل يمكنك أن تدلني على بعض التعليمات البرمجية الحالية التي ترسل إجراءً؟ شكر.

بالتأكيد

من داخل مكون

عمل واحد من ملحمة

حركات متعددة من ملحمة واحدة

آمل أن يساعد هذا: +1:

ترميز سعيد!

أعتقد أن كل هذا القفل / فتح القفل ليس هو أفضل فكرة من حيث وضع الحماية خارج الكود. بدلاً من ذلك ، أعتقد أنه يجب عليك تقييم الكود في إطار iframe على أصل مختلف للتأكد من عدم وجود طريقة للتفاعل مع جلسة Camper.

(بعيدًا ولكن وثيق الصلة قليلاً): ما هي الطريقة المفضلة للإبلاغ عن مشكلات الأمان المحتملة إلى freeCodeCamp؟

@ joker314 لا تتردد في إطلاق لي بريدًا إلكترونيًا [email protected]

يرجى ملاحظة أن هذه المشكلة تم حظرها بواسطة الإصدار رقم 16904

أقوم بإغلاق هذه المشكلة باعتبارها قديمة لأنها لم تكن نشطة مؤخرًا. إذا كنت تعتقد أن هذا لا يزال مناسبًا للنظام الأساسي المحدث حديثًا ، فيرجى توضيح السبب ، ثم إعادة فتحه.