Freecodecamp: कोड लॉक / अनलॉक बटन शुरुआती लोगों के लिए एक भ्रामक यूएक्स है

@tchaffee रिपोर्ट के लिए धन्यवाद, इसे https://github.com/freeCodeCamp/freeCodeCamp/issues/16250 के पक्ष में बंद करना

@raisedadead अंक # 16250 एक अलग समस्या का वर्णन करता है। मेरी चिंता यह है: एक शुरुआती को कैसे पता चलता है कि कोड निष्पादित करने के लिए सुरक्षित है या नहीं? उपयोगकर्ता का अनुभव खराब है क्योंकि किसी भी तरह से शुरुआत करने वाले के पास निर्णय लेने की जानकारी नहीं है।

ठीक है ... इसका मतलब है कि हमें बोर्डिंग के लिए एक कदम चुनौती की आवश्यकता होगी।

@QuincyLarson क्या आपके मन में कुछ है?

या हो सकता है कि हम फिर से शुरू करें कि हमने इस आवश्यकता के लिए कैसे शुरू किया? क्या स्थानीय भंडारण से कोई जोखिम कोड चल रहा है? मुझे URI में कोई कोड नहीं होने पर भी चेतावनी मिलती है, और यह एक अनावश्यक चेतावनी की तरह लगता है क्योंकि यह सिर्फ मेरा बचा हुआ काम है।

मैं इस उपयोग के मामले की पृष्ठभूमि नहीं जानता, लेकिन मुझे लगता है कि URI में कोड साझा करने के लिए है? और मैं अनुमान लगा रहा हूं कि वास्तविक सुरक्षा जोखिम क्या है?

हो सकता है कि हम शुरुआती प्रोग्रामर से यह तय करने के बजाय कोड साझा करने के लिए एक और समाधान पर विचार कर सकें कि क्या कोड निष्पादित करने के लिए सुरक्षित है। मुझे लगता है कि पहले यह समझना उचित होगा कि मौजूदा समाधान क्या प्रदान करता है और क्या आवश्यकताएं थीं जो हमारे वर्तमान समाधान की ओर ले जाती हैं। या यह मामला हो सकता है कि यूआरआई के माध्यम से कोड साझा करना सिर्फ एक बुरा विचार है।

या हो सकता है कि हम फिर से शुरू करें कि हमने इस आवश्यकता के लिए कैसे शुरू किया? क्या स्थानीय भंडारण से कोई जोखिम कोड चल रहा है? मुझे URI में कोई कोड नहीं होने पर भी चेतावनी मिलती है, और यह एक अनावश्यक चेतावनी की तरह लगता है क्योंकि यह सिर्फ मेरा बचा हुआ काम है।

आवश्यकता अच्छी तरह से स्थापित है। हमें उत्पादन पर कई XSS मुद्दों को संबोधित करना पड़ा है। सबसे हाल ही में साझाकरण को पूरी तरह से अवरुद्ध करने की आवश्यकता थी। एक असुरक्षित कोड को कैसे निष्पादित किया जा सकता है, इस पर कई वैक्टर हैं।

उदाहरण के लिए एक उपयोगकर्ता, कहीं से भी पेस्ट कोड कॉपी कर सकता है, और यह व्यवहार में ऐसे मुद्दों को जन्म दे सकता है। वर्तमान फिक्स इस तरह के एक वेक्टर को रोकता नहीं है, लेकिन तकनीकी रूप से चेतावनी के साथ किसी भी निष्पादन को सीमित करता है। इसके चारों ओर UX एक चिंता का विषय है, और इसलिए इसे सीखने की जरूरत है।

हो सकता है कि हम शुरुआती प्रोग्रामर से यह तय करने के बजाय कोड साझा करने के लिए एक और समाधान पर विचार कर सकें कि क्या कोड निष्पादित करने के लिए सुरक्षित है।

जरूर, क्यों नहीं। एक नज़र लेने के लिए स्वतंत्र महसूस करें और हमें एक समाधान करना पसंद होगा जो वर्तमान सुधार को बढ़ाता है जो मूल रूप से निष्पादन पर एक इन्फ्रा लेवल ब्लॉक है। बेशक, क्या आपको दिलचस्पी होनी चाहिए कि हम एक पीआर के साथ मदद का उपयोग कर सकते हैं।

या यह मामला हो सकता है कि यूआरआई के माध्यम से कोड साझा करना सिर्फ एक बुरा विचार है।

हमारे पास योजनाबद्ध तरीके से डिब्बे हैं, लेकिन जल्द ही ऐसा नहीं हो रहा है, क्योंकि हम इसके चारों ओर इन्फ्रा तैयार कर रहे हैं। Https://github.com/freeCodeCamp/freeCodeCamp/issues/11263 देखें

यह ऐसा था, जब उपयोगकर्ता एकमात्र मॉडल था, और हमें अपने डीबी को हल्का रखना था, हम इसे उत्तरोत्तर रूप से अधिक डिक्रिप्ट करने की योजना बना रहे हैं।

आवश्यकता अच्छी तरह से स्थापित है।

कौनसा? मैं आवश्यकताओं में से एक होने के रूप में स्थानीय भंडारण से प्राप्त कर रहा है कोड को समझते हैं। इससे मुझे समझ में आता है - कैम्पर्स को कोड खोना नहीं चाहिए, जिस पर उन्होंने काम करना शुरू कर दिया है।

क्या यूआरआई से कोड चलाने के लिए एक और आवश्यकता है? मुझे इस बारे में ज्यादा जानकारी नहीं है, यह कुछ हफ्ते पहले मैंने देखा कि सुरक्षा के मुद्दे पर एक घंटी बजती है।

वे दो अलग-अलग लक्ष्यों, और विभिन्न सुरक्षा जोखिमों के साथ दो अलग-अलग आवश्यकताओं की तरह लगते हैं?

एक नज़र लेने के लिए स्वतंत्र महसूस करें और हमें एक समाधान करना पसंद होगा जो वर्तमान सुधार को बढ़ाता है जो मूल रूप से निष्पादन पर एक इन्फ्रा लेवल ब्लॉक है।

मैं एक सुरक्षा विशेषज्ञ नहीं हूं, लेकिन मुझे कुछ चीजों के साथ आने की कोशिश करने में खुशी होगी अगर मैं बेहतर आवश्यकताओं को समझ सकता हूं। क्या कोई व्यक्ति कैम्पर के दृष्टिकोण से सभी आवश्यकताओं का विस्तार से वर्णन कर सकता है, साथ ही सुरक्षा छेद जिसे नवीनतम परिवर्तनों ने ठीक करने का प्रयास किया है? इसके अलावा, "इन्फ्रा लेवल ब्लॉक" क्या है?

हमारे पास योजनाबद्ध तरीके से डिब्बे हैं।

समस्या यह है कि यह क्या है, इसे समझने के लिए पर्याप्त विवरण में उस समाधान का वर्णन नहीं करता है। क्या आप मुझे इस बारे में अधिक जानकारी दे सकते हैं कि "डिब्बे" क्या हैं और कल्पना किए गए समाधान क्या हैं?

वैसे भी, मैं इसे इससे बड़ा कुछ नहीं बनाना चाहता। हो सकता है कि ऑन-बोर्डिंग के लिए एक कदम चुनौती अभी के लिए सही काम है। लेकिन मैं वास्तव में उत्सुक हूं कि उस पर बोर्डिंग कैसा दिखेगा। क्या कैंपर्स को शुरुआत में यह सिखाना संभव है कि किस कोड पर भरोसा किया जाना चाहिए और कौन सा नहीं करना चाहिए? अगर आपके मन में कुछ है, तो मैं इसे देखना चाहूंगा क्योंकि शायद यह उतना आसान है जितना मैं कल्पना कर रहा हूं।

आपकी उत्सुकता के लिए धन्यवाद, परियोजना की वास्तुकला के बारे में। मैं निश्चित रूप से आपके सभी प्रश्नों का उत्तर देना चाहूंगा, लेकिन मुझे डर है, इस धागे पर सब कुछ समझा देना पर्याप्त या उचित नहीं होगा।

मैं समझता हूं कि आप संभवतः इसके साथ शुरू हो रहे हैं, इसलिए मैं यथासंभव स्पष्ट होने की कोशिश करूंगा, लेकिन अगर कुछ अस्पष्ट है तो कृपया अपने प्रश्नों को छोड़ दें।

मैं यह प्रश्न लूंगा और आपको संदर्भ देने की कोशिश करूंगा:

क्या कोई व्यक्ति कैम्पर के दृष्टिकोण से सभी आवश्यकताओं का विस्तार से वर्णन कर सकता है, साथ ही सुरक्षा छेद जिसे नवीनतम परिवर्तनों ने ठीक करने का प्रयास किया है? इसके अलावा, "इन्फ्रा लेवल ब्लॉक" क्या है?

• सबसे पहले, कोड का मूल्यांकन और उत्पादन (freeCodeCamp.org) और क्लाइंट पक्ष पर मचान (beta.freeCodeCamp.org) को कैसे निष्पादित किया जा रहा है, इस पर एक बड़ा अंतर है। इस बारे में चर्चा करना कि थोड़ी गुंजाइश है, इसलिए मैं कोड पर एक नज़र डालने की सलाह दूंगा। लेकिन, बस आपको प्रक्रिया के बारे में एक पक्षी की नज़र से देखना है, इसके संपादक में कोड लेना और इसे ब्राउज़र के संदर्भ में ( निष्कासन , संदर्भ कोड का उपयोग करके) बहुत अलग तरीके से निष्पादित करना है।

• अब, टूरिस्ट के नजरिए पर आ रहा है। उन सभी परिदृश्यों की कल्पना करें जिन्हें आप एक टूरिस्ट के रूप में करेंगे:

  • आप अपने संपादक में संपादन कोड शुरू कर सकते हैं।
  • आप अपने संपादक में कोड पेस्ट कर सकते हैं
  • आप आंशिक रूप से संपादित कर सकते हैं, दूसरी चुनौती पर जा सकते हैं और वापस आ सकते हैं।
  • आप किसी की प्रोफ़ाइल पर जा सकते हैं, व्यू सॉल्यूशन लिंक पर क्लिक कर सकते हैं, या फ़ोरम में एक लिंक पर क्लिक कर सकते हैं, आदि जिसे अन्यथा URI के नाम से जाना जाता है।
  • आप ऐसा कर सकते हैं ...
    या इसके बाद के संस्करण के किसी भी संयोजन संभव है।
• सभी मामलों में, यह उसी संपादक तक पहुंचता है जहां कोड पार्स और मूल्यांकन किया जाएगा।
• यह पार्सिंग टाइप कोड, स्थानीय-भंडारण या यूआरआई से हो सकता है।

• सभी मामलों में, कुछ सुरक्षा जांच की जाएगी, उदाहरण के लिए अनंत लूप सुरक्षा, स्ट्रिपिंग ऑफ और / या टैग को डीबी भेजने से पहले समाधान को एन्कोडिंग करते समय प्रतिस्थापित करना, आदि।

• नहीं के साथ। कई हमले वैक्टर को संभालने के लिए वास्तव में जटिल संयोजन।

• वह सिर्फ सुरक्षा है।

• फिर, वर्कफ़्लो आता है:

  • स्थानीय भंडारण के लिए डीबी को पकड़े बिना, "ऑटो-सेव" कार्य करने के लिए कुछ तरीके की आवश्यकता होती है।
  • ऐसा इसलिए है, क्योंकि केवल सबमिट किए गए और पास किए गए समाधान ही DB में जाने चाहिए।
  • आंशिक समाधान (संपादित या कॉपी-पेस्ट), यानी (सबमिशन + पासिंग या काम में नहीं) को स्थानीय भंडारण पर होना होगा।
  • साथ ही, डीबी और स्थानीय भंडारण के बीच लेनदेन (शेयरिंग / यूआरआई) को पहले बताए गए कारणों से इनकोड / डिकोड करना होगा।

यहाँ लेन-देन से मेरा मतलब है कि एक ऐसी स्थिति में जहाँ संपादक का कोड होता है, एक उपयोगकर्ता द्वारा अपनी प्रोफ़ाइल या अन्य जगहों से साझा लिंक पर क्लिक करने के कारण।

मूल्यांकन के लिए लोडिंग समाधानों की प्राथमिकता Editor > Local Storage > URI/DB

यदि, आप वर्कफ़्लो बनाम परिदृश्यों की तुलना करते हैं, तो संभवतः आपको अधिक विचार मिलेगा कि बे पर अटैक वेक्टर्स को रखते हुए तर्क कितना जटिल हो जाता है।

इसलिए, एक कोड जांच पद्धति के माध्यम से, स्पष्ट सहमति के बिना, सभी चुनौतियों पर संपादक को कुछ भी नहीं चलाने के लिए एक कंबल चेक है। यह इन्फ्रा लेवल ब्लॉक है जिसे मैं ले रहा हूं। यह वह जगह नहीं है, जहां तक ​​ब्राउज़र में एक अलग वातावरण में सभी कोड को निष्पादित करने का एक सुरक्षित तरीका है।

मैं मानता हूं कि यह UX के लिए बुरा हो सकता है। इसलिए ऑन-बोर्डिंग एक तरीका हो सकता है, यह दिखाने के लिए, कि इसकी आवश्यकता क्यों है, बहुत अधिक जटिलता के बिना, और नए उपयोगकर्ताओं को डराने के लिए।

अंत में, डिब्बे कुछ इसी तरह के होंगे जैसे कि छोटे लिंक , जहाँ आप देखते हैं। Ex: कोडपेन, jsbin आदि नोट: मैं यहाँ विचार को सरल बना रहा हूँ।

ये हमारी मदद कर सकते हैं, वर्तमान प्राथमिकता के बिना कोड को सुरक्षित रूप से संग्रहीत / देखने में।

इसलिए,

वास्तविक UX फिक्स केवल ऑन-बोर्डिंग चुनौती में, चेतावनी को समझा रहा है।

कृपया, ध्यान दें कि मेरे पास यहां की सरलीकृत चीजें हो सकती हैं। यदि आपकी रुचि है, तो मैं कोड की जाँच करने की सलाह दूंगा। यदि अटक गया, तो हम उस मोर्चे पर किसी भी समझ को संबोधित करने के लिए खुले हैं। तो कृपया यहां किसी भी प्रश्न को छोड़ दें।

फिर से पुन: पुनरावृति के लिए:

1. हां, कई आवश्यकताएं हैं, लेकिन सभी में निष्पादन / मूल्यांकन और देखने के लिए प्रवेश का एक ही बिंदु है। इसलिए लॉकिंग / अनलॉकिंग की आवश्यकता है। वे सभी समान सुरक्षा जोखिमों का नेतृत्व करते हैं।
2. यह अब के रूप में है, मूल्यांकन तंत्र में कोड के सभी आने वाले रास्तों पर एक कंबल की जांच।
3. हमें निश्चित रूप से कुछ सीखने के रूप में UX को संबोधित करने की आवश्यकता है:

क्या कैंपर्स को शुरुआत में यह सिखाना संभव है कि किस कोड पर भरोसा किया जाना चाहिए और कौन सा नहीं करना चाहिए? अगर आपके मन में कुछ है, तो मैं इसे देखना चाहूंगा क्योंकि शायद यह उतना आसान है जितना मैं कल्पना कर रहा हूं।

1. कोड, चुनौती के समाधान के लिए

2. कोड, जो किसी और द्वारा बनाया गया था (अपनी स्वयं की प्रोफ़ाइल से लिंक सहित), विश्वसनीय नहीं है, और एक बार समीक्षा की जानी चाहिए। वे बस जाँच कर सकते हैं कि संपादक में समाधान उनके लिए समझ में आता है। क्योंकि, अगर वे किसी भी यादृच्छिक कोड को अनलॉक कर रहे हैं, बिना यह समझे कि यह क्या है, तो वे शायद कुछ संभावित सुरक्षा गार्डों को जोखिम में डाल सकते हैं।

हमें केवल उपरोक्त दो बिंदुओं के आसपास एक क्रिया तैयार करने की आवश्यकता है, और एक ऑन-बोर्डिंग चुनौती का निर्माण करना है।

आशा है कि यह आपको कुछ संदर्भ देता है? यदि आप अधिक प्रश्न जोड़ने के लिए स्वतंत्र महसूस नहीं करते हैं। खुश योगदान!

@raisedadead आपकी विस्तृत व्याख्या से बहुत मदद मिलती है। मेरे पास कुछ और प्रश्न / अवलोकन हैं जो मुझे आशा है कि हमें सर्वोत्तम अल्पकालिक और दीर्घकालिक कार्यान्वयन की ओर ले जाएंगे।

इसके संपादक में कोड ले रहा है और इसे ब्राउज़र के संदर्भ में निष्पादित कर रहा है (eval का उपयोग करके)

यह सुरक्षा के मुद्दों को बनाने वाला कमजोर बिंदु है। मैं यह नहीं कह रहा हूं कि यह परिहार्य है, लेकिन यह ध्यान देने योग्य बात है कि यह किसी के दिमाग में घूमने की स्थिति में है क्योंकि कोई व्यक्ति समान कार्यक्षमता प्रदान करने का अधिक सुरक्षित तरीका लेकर आया है। शायद इसलिए नहीं कि दिन के अंत में आपको कोड निष्पादित करना होगा। लेकिन हम इसके बारे में एक खुला दिमाग रखें। मैं आसपास पूछने के लिए प्रतिबद्ध हूँ।

आइए कार्यक्षमता और आवश्यकताओं के बारे में थोड़ा करीब से देखें:

आंशिक समाधान (संपादित या कॉपी-पेस्ट), यानी (सबमिशन + पासिंग या काम में नहीं) को स्थानीय भंडारण पर होना होगा।

कोड, चुनौती के समाधान के लिए बनाए गए टूरिस्ट (या तो मैन्युअल रूप से टाइप करके, या किसी अन्य संपादक से कॉपी / पेस्ट) पर भरोसा किया जाता है।

ऊपर से यह मुझे ऐसा लगता है जैसे स्थानीय भंडारण से कोड पर भरोसा किया जाना चाहिए, लेकिन भरोसा नहीं किया जा रहा है। क्या कोड के बीच अंतर करने का एक तरीका है जो एक यूआरआई (निश्चित रूप से विश्वसनीय नहीं) से आता है और जिस कोड को मैंने पहले टाइप किया था, वह आपके स्थानीय भंडारण से आता है? यह छोटा परिवर्तन अकेले UX को बहुत बेहतर बना देगा। खासकर जब से हम संदेश को अधिक विशिष्ट बना सकते हैं: "आपने इसमें कोड के साथ एक यूआरआई का उपयोग किया है, क्या आप कोड पर भरोसा करते हैं?"

यदि यह पता लगाना संभव है और केवल एक यूआरआई से आने वाले कोड पर भरोसा नहीं करना है, तो मुझे लगता है कि यह मौजूदा वर्कफ़्लो और कार्यक्षमता में अच्छी तरह से फिट हो सकता है। यदि कोड URI से आता है, तो जब तक उपयोगकर्ता "कोड लॉक / अनलॉक" नहीं करता है, तब तक हम किसी भी कोड को लोकल स्टोरेज में सेव नहीं करेंगे? बटन। जिसके बाद उपयोगकर्ता ने संकेत दिया कि उन्हें कोड पर भरोसा है, इसलिए इसे सुरक्षित रूप से स्थानीय भंडारण में रखा जा सकता है और फिर वापस आने पर भविष्य में बिना किसी चेतावनी के निष्पादित किया जा सकता है।

लंबे समय तक, मैं निश्चित रूप से सवाल कर रहा हूं कि क्या यूआरआई में कोड भेजना कुल मिलाकर एक बुरा विचार है, और अगर हम समाधान और कोड साझा करने का एक बेहतर तरीका ढूंढ सकते हैं। लेकिन मैं यह दोहराता हूं कि यह एक लंबी अवधि का प्रश्न है क्योंकि इसे वर्तमान में किए जाने वाले तरीकों में कुछ बड़े बदलावों की आवश्यकता है।

वे बस जाँच कर सकते हैं कि संपादक में समाधान उनके लिए समझ में आता है।

इससे मुझे यकीन हो गया कि ऑन-बोर्डिंग काफी सरल हो सकती है जो प्रभावी हो। "यदि आप संपादक में कोड को नहीं पहचानते या समझते हैं, तो उस पर भरोसा न करें।"

लेकिन अगर यूआरआई और स्थानीय भंडारण में कोड से आने वाले कोड के बीच अंतर करना संभव है तो मैं यह भी सवाल कर रहा हूं कि क्या ऑन-बोर्डिंग आवश्यक है, क्योंकि केवल उस स्थिति में चेतावनी मुझे खराब यूएक्स की तरह नहीं लगती है। "आपने यूआरआई से सिर्फ कोड का उपयोग किया है, कृपया इसे अनलॉक करने से पहले संपादक में कोड को सुनिश्चित करें।"

@raisedadead मुझे नहीं पता कि क्या आप @tchaffee से पहले मिल चुके हैं, लेकिन वह एक बहुत अच्छा योगदान देने वाला है फ्रीकोड। वह एक अनुभवी डेवलपर है, और हमारी नई परीक्षण योग्य परियोजनाओं के पीछे मुख्य लोगों में से एक है।

ठीक है ... इसका मतलब है कि हमें बोर्डिंग के लिए एक कदम चुनौती की आवश्यकता होगी।

हम और अधिक कदम चुनौतियों को जोड़ना नहीं चाहते हैं। अगर कुछ भी हो, तो हम अपने पास मौजूद चुनौतियों से छुटकारा पाना चाहते हैं।

ऐसा इसलिए है क्योंकि लोग पढ़ते नहीं हैं ।

जिन कारणों से हम चुनौती पाठ पाठ को संभव बनाने की कोशिश करते हैं उनमें से एक यह है कि जितना अधिक पाठ होगा, उतना ही कम होगा कि उपयोगकर्ता के पास इसे पढ़ने के लिए धैर्य होगा।

@tchaffee सही है - हमें इस के UX में सुधार करने की आवश्यकता है।

मैं प्रस्ताव करता हूं कि हम केवल उस कोड को लॉक करें यदि वे किसी ऐसे URL पर क्लिक करके चुनौती पर पहुंचे हैं जिसमें किसी और का कोड है। अन्यथा, हमें उन्हें कोड चलाने के बारे में चेतावनी नहीं देनी चाहिए।

JSBin, CodePen, मुझे नहीं लगता कि इनमें से कोई भी साइट इस तरह के अन्य लोगों के कोड चलाने के बारे में लोगों को चेतावनी देती है। मुझे लगता है कि हम उन्हें चेतावनी दे सकते हैं, लेकिन केवल उन स्थितियों में जहां यह संभावना है कि वे कोड चला रहे हैं जो उनका नहीं है। अन्यथा, उस बटन पर क्लिक करना वास्तव में कष्टप्रद है और इससे आकर्षण बढ़ेगा।

आप अपने संपादक में संपादन कोड शुरू कर सकते हैं।

ताला की जरूरत नहीं।

आप अपने संपादक में कोड पेस्ट कर सकते हैं

किसी लॉक की आवश्यकता नहीं है (हमें यह मानकर चलना चाहिए कि आप उस कोड को पहले ही पढ़ चुके हैं जिसे आप पेस्ट कर रहे हैं)

आप आंशिक रूप से संपादित कर सकते हैं, दूसरी चुनौती पर जा सकते हैं और वापस आ सकते हैं।

ताला की जरूरत नहीं

आप किसी की प्रोफ़ाइल पर जा सकते हैं, दृश्य समाधान लिंक पर क्लिक कर सकते हैं, या फ़ोरम में लिंक पर क्लिक कर सकते हैं, आदि।

यह एकमात्र ऐसी स्थिति है जब ताला को इमो की आवश्यकता होती है।

इसके अलावा, हमें इस पर फिर से विचार करने की आवश्यकता है जहां हमें एक हॉवर संदेश की आवश्यकता नहीं है। हम कोडबेस में कहीं और ऑन-होवर संदेशों का उपयोग नहीं करते हैं, और इसलिए नहीं करना चाहिए क्योंकि वे मोबाइल पर काम नहीं करते हैं। हमारे द्वारा उपयोग किए जाने वाले सभी पाठ को बटन पर ही लिखा जाना चाहिए।

हमारे द्वारा उपयोग किए जाने वाले सभी पाठ को बटन पर ही लिखा जाना चाहिए।

मुझे लगता है कि मौजूदा बटन टेक्स्ट काम कर सकता है यदि आप "मेरी कोड लॉक क्यों है?" की तर्ज पर बटन के नीचे एक लिंक दिखाते हैं। केवल एक सलाह।

इसके अलावा, मैं इस मुद्दे को लेने की कोशिश कर सकता हूं अगर किसी और के पास इसके लिए समय नहीं है। मुझे किसी को सभी संबंधित कोड की ओर इशारा करते हुए कुछ मदद की आवश्यकता होगी। लेकिन अगर कोई और अधिक योग्य और इच्छुक है तो निश्चित रूप से उन्हें इस मुद्दे को लेने दें।

@tchaffee यह बहुत अच्छा होगा!

एक लिंक के बजाय हमें केवल एक संक्षिप्त तरीका निकालने की आवश्यकता है ताकि इसे कुछ शब्दों में समझा जा सके, भले ही बटन दो पंक्तियों का हो। "मुझे इस कोड पर भरोसा है। इसे अनलॉक करें।"

फिर से, हम केवल यह बटन दिखाना चाहते हैं जब कोड टूरिस्ट का नहीं है।

@QuincyLarson हाँ, जबकि मैं भी ऑन-बोर्डिंग प्रवाह से बचना चाहूंगा, और केवल लेबल को अपडेट करूंगा।

यह अभी भी इस तथ्य को छोड़ देता है कि वर्तमान ग्राहक पक्ष तर्क के अनुसार, केवल गैर-उपयोगकर्ता कोड को अवरुद्ध करने के कार्यान्वयन को लागू करना होगा।

इसके द्वारा मेरा मतलब है कि बटन "I trust this code. Unlock it." का तर्क केवल तभी प्रदर्शित किया जा सकता है जब URI से कोड आता है, आदि को अभी भी लागू करने की आवश्यकता है।

मैं लेबल को अपडेट करने के लिए एक पीआर जोड़ूंगा और अन्य मुद्दे को बंद कर दूंगा https://github.com/freeCodeCamp/freeCodeCamp/issues/16250

यह अभी भी इस तथ्य को छोड़ देता है कि वर्तमान ग्राहक पक्ष तर्क के अनुसार, केवल गैर-उपयोगकर्ता कोड को अवरुद्ध करने के कार्यान्वयन को लागू करना होगा।

निश्चित नहीं कि यह नया व्यवहार लागू करने के लिए मेरा प्रस्ताव कहां छोड़ता है। मैं केवल गैर-उपयोगकर्ता कोड को अवरुद्ध करने का प्रयास कर सकता हूं, लेकिन ऐसा लगता है कि अब सही समय नहीं है? क्या कोई स्पष्ट कर सकता है?

मुझे दोहरी जांच करनी होगी, कि यह कैसे किया जाना है, इस पर आपको बहुत ही विशिष्ट दिशानिर्देश देने के लिए काम करता है, इस बीच मैं उसके इनपुट के लिए @BerkeleyTrue को टैग करूंगा।

इसके द्वारा मैं बटन के लिए तर्क का अर्थ है "मुझे इस कोड पर भरोसा है। इसे अनलॉक करें।" URI से कोड आने पर ही प्रदर्शित किया जा सकता है, आदि को अभी भी लागू करने की आवश्यकता है।

@raisedadead हाँ - मैं आपसे सहमत हूँ। ऐसा करना महत्वपूर्ण है और हजारों शिविरार्थियों को उनकी पवित्रता से बचाएगा।

मैंने अपनी बीटा रिलीज़ कानबन पर इसे "महत्वपूर्ण पथ" में स्थानांतरित कर दिया है: https://github.com/freeCodeCamp/freecodecamp/projects/1?fullscreen=true

मैं अभी भी इसे देने के लिए खुश हूँ अगर कोई मुझे प्रश्न में कोड के कुछ हिस्सों को इंगित कर सकता है। मुझे यकीन है कि मैं इसे स्वयं पा सकता हूं, लेकिन अगर कोई पहले से ही कोड से परिचित है तो यह कुछ समय बचाएगा। क्या कोई मुझे बता सकता है कि इस की स्थिति क्या है?

@tchaffee आपके धैर्य के लिए धन्यवाद।

@ बाउंसी क्या आप जानते हैं कि यह तर्क कोडबेस में कहाँ रहता है? क्या आप सही दिशा में @tchaffee इंगित कर सकते हैं?

@tchaffee

आप pathnameSelector साथ URI की जाँच कर सकते हैं

आप इसे mapStatetoProps साइडपैनल घटक की विधि में पास करके ToolPanel घटक के साथ बातचीत कर सकते हैं।

आशा है कि यह मदद करता है 👍

मैंने इस पर एक नज़र रखना शुरू किया और मेरे पास एक सवाल है। क्या कोई मुझे उदाहरण दे सकता है कि निम्नलिखित कार्य कैसे संभव है:

आप किसी की प्रोफ़ाइल पर जा सकते हैं, व्यू सॉल्यूशन लिंक पर क्लिक कर सकते हैं, या फ़ोरम में एक लिंक पर क्लिक कर सकते हैं, आदि जिसे अन्यथा URI के नाम से जाना जाता है।

बीटा साइट पर मैं केवल समाधान के लिए एक पॉपअप देख रहा हूं और कोड लोड करने वाला कोई भी यूआरआई नहीं है। तो लगता है कि यह बीटा में बदल गया है? क्या कोई अन्य स्थान हैं जहां यूआरआई से कोड लोड किया जा सकता है? क्या कोई मुझे एक उदाहरण यूआरआई की ओर इशारा कर सकता है?

धन्यवाद!

@tchaffee जो सही है, यह उपयोग मामला अब मान्य नहीं है:

आप किसी की प्रोफ़ाइल पर जा सकते हैं, व्यू सॉल्यूशन लिंक पर क्लिक कर सकते हैं, या फ़ोरम में एक लिंक पर क्लिक कर सकते हैं, आदि जिसे अन्यथा URI के नाम से जाना जाता है।

यह वास्तव में अब एक मोडल के साथ बदल दिया गया है, जिससे यह संपादक में URI को पार्स करने की तुलना में सुरक्षित हो गया है। इसलिए मुझे लगता है कि URI से लोडिंग अब तस्वीर में नहीं है।

अब, यह हमें कोड लॉकिंग / अनलॉकिंग के लिए लाता है। वह तब है जब बटन को दिखाया जाना चाहिए।

यहाँ कुछ परिदृश्य हैं जिनके बारे में मैं सोच सकता हूँ:

1. मैप से कैंपर्स एक चुनौती पर जा सकते हैं।
2. ऐसे मामले में, यदि उपलब्ध हो, तो कोड स्थानीय कोड से संपादक में लोड किया जाएगा।
3. या, इसे बैकएंड से प्राप्त किया जाएगा, स्थानीय भंडारण में जोड़ा जाएगा और फिर संपादक में रखा जाएगा।

अब, एक आदर्श दुनिया में यह मामला होने वाला है, कि यह कोड टूरिस्ट के स्वामित्व में है।

लेकिन, जो भी संभावनाओं के लिए, वह कोड है जिसे संपादक पर लोड किया गया है, और निष्पादित किया गया है। यह हमें एक ऐसी जगह के साथ छोड़ देता है जहाँ अन-सिक्योर कोड को अंजाम दिया जा सकता है? कम से कम यह एक वेक्टर है जिसे मैं देख सकता हूं।

इसलिए, हमें यह सुनिश्चित करना होगा कि कैम्पर को पता चले कि क्या निष्पादित किया जाना है, और वहाँ स्पष्ट सहमति के साथ किया जाता है।

इसलिए, स्थानीय भंडारण या बैकएंड (गैर-उपयोगकर्ता कोड) से कोड को अवरुद्ध करने का हिस्सा अभी भी बना हुआ है, मुझे लगता है। लेकिन, इसके लिए बटन होने से कुछ मुझे लगता है कि गैर-जरूरी है।

गैर-उपयोगकर्ता कोड को लॉक करना संभव होना चाहिए, जो कि इसे निष्पादित नहीं करता है, अगर यह मूल बीज कोड या किसी चीज़ से अलग होता है जो टूरिस्ट (उपयोगकर्ता-कोड) द्वारा टाइप किया गया था।

@Bouncey @BerkeleyTrue Am मैं इस दृश्य में सही हूँ?

ओह, हाँ और केवल यह ध्यान दें कि यूआरआई पार्सिंग अभी भी उपलब्ध है, और नहीं-जहाँ जा रहा है क्योंकि चुनौती संपादक इस तथ्य के अज्ञेय है कि हमारे पास समाधानों के लिए मोडल के साथ एक प्रतिक्रिया प्रोफ़ाइल दृश्य है।

मैं कोशिश करूँगा और कुछ समय मिलने पर एक उदाहरण URI साझा करूँगा।

लेकिन, जो भी संभावनाओं के लिए, वह कोड है जिसे संपादक पर लोड किया गया है, और निष्पादित किया गया है। यह हमें एक ऐसी जगह के साथ छोड़ देता है जहाँ अन-सिक्योर कोड को अंजाम दिया जा सकता है?

मैं कहूंगा कि यह नहीं है। यदि कोई कैम्पर कहीं और से कोड कॉपी / पेस्ट करता है, तो यह सुनिश्चित करने के लिए है कि वे कोड को समझते हैं, और यह कि कोड सुरक्षित है। यह दृष्टिकोण ईमानदारी को भी पुरस्कृत करता है और धोखाधड़ी को दंडित करता है - यदि आपको समझ में नहीं आता है कि क्या कॉपी किया गया कोड है तो आपको इसे कभी भी चिपकाना नहीं चाहिए। आप स्पष्ट रूप से इसे स्वयं नहीं लिख सकते थे यदि आप इसे नहीं समझते हैं, तो आपके द्वारा किए गए किसी भी नुकसान का कारण वास्तविक धोखा है।

पहली बार संपादक में कोड प्राप्त करने के केवल दो "ईमानदार" तरीके हैं?

1. आप जो कुछ समझते हैं उसे कॉपी / पेस्ट कर सकते हैं और खुद लिख सकते हैं।
2. अपने आप को कोड में टाइप करें।

किस बिंदु पर इसे स्थानीय संग्रहण या बैकएंड में सहेजा गया है?

कोई भी कोड जो स्थानीय भंडारण या बैकएंड से आता है और संपादक में रखा जाता है, पहले ऊपर दिए गए तरीकों में से एक से आना था। इसलिए स्थानीय भंडारण या बैकएंड से कोड को हमेशा सुरक्षित माना जा सकता है।

गैर-उपयोगकर्ता कोड को लॉक करना संभव होना चाहिए, जो कि इसे निष्पादित नहीं करता है, अगर यह मूल बीज कोड या किसी चीज़ से अलग होता है जो टूरिस्ट (उपयोगकर्ता-कोड) द्वारा टाइप किया गया था।

ऊपर, IMO इसकी जरूरत नहीं है।

URI पार्सिंग अभी भी उपलब्ध है, और नहीं-जहाँ जा रहा है क्योंकि चुनौती संपादक इस तथ्य के अज्ञेय है कि हमारे पास समाधान के लिए मोडल के साथ एक प्रतिक्रिया प्रोफ़ाइल दृश्य है।

यह एकमात्र गैर-सुरक्षित वेक्टर है जिसके बारे में मैं सोच सकता हूं। यदि आप मुझे एक उदाहरण दे सकते हैं तो मैं इसका पता लगाने की कोशिश करूंगा और केवल इस मामले में "अनलॉक" बटन दिखाऊंगा।

बेशक अगर मैंने कुछ याद किया है, तो कृपया मुझे सुधारें।

हां, आपके द्वारा बताए गए पहले दो बिंदु कोड लॉक करने के लिए सबसे कम मामले परिदृश्य हैं, जिनसे मैं सहमत हूं। और आदर्श रूप से हमें इसे रोकना चाहिए। इसका महंगा काम करना है।

किस बिंदु पर इसे स्थानीय संग्रहण या बैकएंड में सहेजा गया है?

जैसे ही संपादक में कोई कोड उपलब्ध होता है, उसे सहेज लिया जाता है। इसलिए कॉपी पेस्ट करना और टाइप करना उसी में गिना जाता है।

यह एकमात्र गैर-सुरक्षित वेक्टर है जिसके बारे में मैं सोच सकता हूं। यदि आप मुझे एक उदाहरण दे सकते हैं तो मैं इसका पता लगाने की कोशिश करूंगा और केवल इस मामले में "अनलॉक" बटन दिखाऊंगा।

यह एकमात्र मामला है जिसे संभालने की आवश्यकता है। और फिर से यह अब के लिए प्राथमिकता नहीं है। इसके लिए उपयोग का मामला तब कहा जाएगा जब हमारे पास URI के माध्यम से हमारे वेब ऐप में तीसरे पक्ष के एकीकरण से आने वाले समाधान होंगे।

इसलिए, चेक का होना पर्याप्त है, और जैसा कि आपने सही तरीके से पता लगाया है, हमें समझदारी से केवल इसे रोकना चाहिए।

मैं एक उदाहरण URI asap साझा करूँगा। (स्टुअर्ट अगर आप सक्षम हैं, तो कृपया मुझे आज़ाद महसूस कराएं, हालांकि)

@raisedadead स्पष्टीकरण के लिए धन्यवाद। मैं इस बात से सहमत हूं कि हमें केवल तभी बटन को लॉक करना चाहिए जब उपयोगकर्ता पहली बार किसी चुनौती को लोड करता है और URL में कोड पैरामीटर होते हैं। अन्य सभी स्थितियों में, हमें कोड को लॉक नहीं करना चाहिए, और उपयोगकर्ता द्वारा बटन क्लिक करने या ctrl + हिट करने पर पहली बार दर्ज करने पर इसे बस चलाना चाहिए।

जैसे ही कोई मुझे URL में कोड का उदाहरण दे सकता है, मैं इस पर काम करना शुरू कर सकता हूं।

@tchaffee हम यहाँ URI में कोड के लिए परीक्षण करते

आप इस तरह से अगर ब्लॉक में कोड लॉक करने के लिए एक कार्रवाई भेज सकते हैं

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

जब तक हम आपको एक कोड URI नहीं दे सकते, तब तक आपको उत्पादक रखना चाहिए

@tchaffee यहां एक उदाहरण है URL: http: // localhost : 3000 / चुनौतियाँ /% 20%% 20% 20 %indromromes? solution = function% 20palindrome (str)% 20% 7B% 0A% 20% 20str 20% 20% 3D% 20str.toLowerCase? () .replace (% 2F% 5 ब% 5CW_% 5D% 2FG% 2C% 20% 27% 27)% 3 बी% 0A% 20% 20For (वर% 20i% 20% 3 डी% 200% 2C% 20len% 20% 3 डी % 20str.length% 20% 201% 3 बी% 20i% 20% -3 सी% 20len% 2F2% 3 बी% 20i% 2 बी% 2 बी)% 20% 7B% 0A% 20% 20% 20% 20if (str% 5Bi% 5D 20%!% 3 डी% 3 डी% 20str% 5Blen-मैं% 5D)% 20% 7B% 0A% 20% 20% 20% 20% 20% 20return% 20false% 3 बी% 0A% 20% 20% 20% 20% 7 दिन % 0A% 20% 20% 7 दिन% 0A% 20% 20return% 20true% 3 बी% 0A% 7 दिन

इससे http: // localhost : 3000 / चुनौतियां / चेक-फॉर-पलिंड्रोम्स URL जाएगा और निम्नलिखित कोड पॉप्युलेट करेगा:

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 / चुनौतियां / जावास्क्रिप्ट-एल्गोरिदम-और-डेटा-संरचनाएँ-प्रोजेक्ट्स / पैलिंड्रोम-चेकर? समाधान = फ़ंक्शन% 20palindrome (str)% 20% 7B% 0A? % 20% 20str% 20% 3 डी% 20str.toLowerCase ()। की जगह (% 2F% 5 ब% 5CW_% 5D% 2FG% 2C% 20% 27% 27)% 3 बी% 0A% 20 20For (वर% 20i% 20% % 3 डी% 200% 2C% 20len% 20% 3 डी% 20str.length% 20% 201% 3 बी% 20i% 20% -3 सी% 20len% 2F2% 3 बी% 20i% 2 बी% 2 बी)% 20% 7B% 0A 20% % 20% 20% 20if (str% 5Bi% 5D% से 20!% 3 डी% 3 डी% 20str% 5Blen-मैं% 5D)% 20% 7B% 0A% 20% 20% 20% 20% 20% 20return% 20false% 3 बी % 0A% 20% 20% 20% 20% 7 दिन% 0A% 20% 20% 7 दिन% 0A% 20% 20return% 20true% 3 बी% 0A% 7 दिन

बस इसे यहाँ प्रलेखन के लिए डाल रहा हूँ। टिप्पणी करने की आवश्यकता नहीं है।

@ बाउंटी क्या आप मुझे कुछ मौजूदा कोड की ओर

ज़रूर

एक घटक के भीतर से

एक महाकाव्य से एक एकल कार्रवाई

एक महाकाव्य से कई कार्य

आशा है कि यह मदद करता है: +1:

हैप्पी कोडिंग!

मुझे लगता है कि यह सब लॉकिंग / अनलॉकिंग सैंडबॉक्सिंग ऑफ कोड के संदर्भ में सबसे अच्छा विचार नहीं है। इसके बजाय, मुझे लगता है कि आपको एक अलग मूल पर iframe में कोड का मूल्यांकन करना चाहिए ताकि यह सुनिश्चित हो सके कि कैंपर के सत्र के साथ बातचीत करने का कोई तरीका नहीं है।

(एक तरफ लेकिन थोड़ा प्रासंगिक): फ्रीकोडकोड में संभावित सुरक्षा मुद्दों की रिपोर्टिंग के लिए पसंदीदा तरीका क्या है?

@ joker314 बेझिझक मुझे एक ईमेल [email protected] शूट करें

कृपया ध्यान दें कि यह समस्या # 16904 अंक से अवरुद्ध है

मैं इस मुद्दे को बासी के रूप में बंद कर रहा हूं क्योंकि यह हाल ही में सक्रिय नहीं हुआ है। यदि आपको लगता है कि यह अभी भी नए अपडेट किए गए प्लेटफॉर्म के लिए प्रासंगिक है, तो कृपया समझाएं, फिर इसे फिर से खोलें।