वीडियो और उपशीर्षक · डायरेक्ट मीडिया डाउनलोडर
क्यों CORS ब्राउज़र में सीधे डाउनलोड को ब्लॉक कर सकता है, और इसका क्या मतलब है
· यह काम किस प्रकार करता है
कोर http डाउनलोड
एक ब्राउज़र-केवल डाउनलोडर समान-मूल नीति के अंदर रहता है। यह पोस्ट बताती है कि CORS क्या है, क्यों कुछ होस्ट फ़ेच की अनुमति देते हैं और अन्य नहीं देते हैं, और रिले सर्वर के बिना एक टूल इसके आसपास काम क्यों नहीं कर सकता है।
लिंक एक नए टैब में काम करता है लेकिन टूल में विफल रहता है - CORS त्रुटि उपयोगकर्ताओं के लिए पहेली पैदा करती है
एड्रेस बार में दर्ज होने पर पॉडकास्ट एनक्लोजर चल सकता है, लेकिन जब कोई पेज फ़ेच के साथ इसे पढ़ने का प्रयास करता है तो विफल हो जाता है। नेविगेशन और स्क्रिप्टेड रीडिंग अलग-अलग ब्राउज़र शक्तियाँ हैं। पहला एक संसाधन प्रदर्शित करता है; दूसरा अपने बाइट्स को किसी अन्य मूल पर चल रहे कोड में उजागर कर सकता है।
डायरेक्ट मीडिया डाउनलोडर को दूसरी शक्ति की आवश्यकता होती है क्योंकि यह प्रतिक्रिया खंडों को पढ़ता है, प्रगति की रिपोर्ट करता है, ब्लॉब बनाता है, और एक नामित सेव प्रदान करता है। जब मीडिया होस्ट ने उस क्रॉस-ओरिजिनल रीड का विकल्प नहीं चुना है, तो ब्राउज़र JavaScript को प्रतिक्रिया प्राप्त करने से रोक देता है, भले ही सामान्य नेविगेशन अभी भी काम कर सकता है। वही अंतर बताता है कि किसी अन्य एप्लिकेशन में पते की प्रतिलिपि बनाने से किसी भी एप्लिकेशन द्वारा दूरस्थ फ़ाइल को बदले बिना एक अलग परिणाम क्यों मिल सकता है।
एक पैराग्राफ में समान-मूल नीति - क्यों toolacre.com पर एक पेज किसी अन्य मूल से परोसे गए बाइट्स को स्वतंत्र रूप से नहीं पढ़ सकता है
एक मूल योजना, होस्टनाम और पोर्ट को जोड़ता है। इसलिए ToolAcre से प्रदत्त एक पेज और प्रकाशक CDN से प्रदत्त फ़ाइल का मूल आमतौर पर अलग-अलग होता है। समान-मूल नीति एक मूल की स्क्रिप्ट को दूसरे मूल की प्रतिक्रियाओं को स्वतंत्र रूप से पढ़ने से रोकती है, परिवेश ब्राउज़र पहुंच के माध्यम से उजागर होने वाले डेटा की सुरक्षा करती है।
यह प्रतिबंध ब्राउज़र द्वारा लागू किया जाता है, न कि डाउनलोडर में आविष्कृत चेतावनी द्वारा। यह एप्लिकेशन कोड द्वारा संरक्षित हेडर या बॉडी भागों का निरीक्षण करने से पहले लागू होता है। स्रोत होस्ट को अभी भी अनुरोध प्राप्त हो सकता है, इसलिए अवरुद्ध रीड को कभी भी "कुछ भी संपर्क नहीं किया गया" के रूप में वर्णित नहीं किया जाना चाहिए। मूल सीमाएँ पठनीय प्रतिक्रियाओं पर लागू होती हैं, न कि केवल फ़ाइल एक्सटेंशन पर, इसलिए स्पष्ट रूप से स्पष्ट `.mp3` प्रत्यय पेज स्क्रिप्ट को कोई विशेष छूट नहीं देता है।
एक्सेस-कंट्रोल-अनुमति-उत्पत्ति क्या करती है - फ़ाइल का होस्ट, टूल नहीं, यह कैसे तय करता है कि ब्राउज़र बाइट्स सौंप सकता है या नहीं
रिमोट सर्वर उचित `Access-Control-Allow-Origin` हेडर लौटाकर ऑप्ट इन कर सकता है। वह निर्णय फ़ाइल होस्ट के कॉन्फ़िगरेशन से संबंधित है। ToolAcre किसी अन्य की प्रतिक्रिया में हेडर नहीं जोड़ सकता है, और अनुरोध विकल्प प्राप्तकर्ता सर्वर द्वारा रोकी गई अनुमति नहीं दे सकता है।
एक अनुमेय हेडर ब्राउज़र को पेज पर प्रतिक्रिया प्रदर्शित करने की अनुमति देता है; यह कॉपीराइट, सुरक्षा या मीडिया गुणवत्ता को प्रमाणित नहीं करता है। इसी तरह, एक गुम हेडर यह साबित नहीं करता कि URL टूटा हुआ है। इसका मतलब केवल यह है कि इस क्रॉस-ओरिजिन स्क्रिप्ट में सर्वर द्वारा लौटाए गए डेटा को पढ़ने की अनुमति नहीं है। होस्ट प्रशासकों को सटीक अनुरोध मूल और उन तरीकों का परीक्षण करना चाहिए जिनका वे समर्थन करना चाहते हैं, बजाय संपूर्ण स्टोरेज नेमस्पेस में आँख बंद करके अनुमति हेडर जोड़ने के।
अवरुद्ध क्रॉस-ओरिजिन रीड्स और स्क्रिप्ट को कोई सहेजने योग्य प्रतिक्रिया क्यों नहीं मिलती है
डाउनलोडर `no-cors` के बजाय सामान्य CORS-मोड फ़ेच का उपयोग करता है। अस्वीकृत क्रॉस-ओरिजिन रीड पर, फ़ेच अस्वीकार कर देता है और एप्लिकेशन कोड को न तो प्रयोग करने योग्य हेडर और न ही कोई बॉडी प्राप्त होती है। टूल संयुक्त `CORS_OR_NETWORK` कैटेगरी की रिपोर्ट करता है क्योंकि ब्राउज़र जानबूझकर प्रत्येक परिवहन विफलता से CORS को अलग करने के लिए पर्याप्त विवरण प्रकट नहीं करते हैं।
अपारदर्शी प्रतिक्रियाएँ स्पष्ट `no-cors` अनुरोधों से संबंधित हैं, लेकिन वह मोड इस कार्य को हल नहीं करेगा: JavaScript एक अपारदर्शी निकाय का निरीक्षण नहीं कर सकता है और इसे इच्छित ब्लॉब में नहीं बदल सकता है। इसलिए कार्यान्वयन अपठनीय प्रतिक्रिया प्राप्त करने और इसे सहेजने का दिखावा करने के बजाय ईमानदारी से विफल हो जाता है। क्योंकि एप्लिकेशन कभी भी उन छिपे हुए बाइट्स को प्राप्त नहीं करता है, यह प्रगति की सही गणना नहीं कर सकता है, संरक्षित हेडर से फ़ाइल नाम का अनुमान नहीं लगा सकता है, या उनसे एक उपयोगी ऑब्जेक्ट URL नहीं बना सकता है।
कार्यान्वित उदाहरण: नेटवर्क पैनल में विफल अनुरोध को पढ़ना - लापता हेडर का पता लगाना और पुष्टि करना कि किसी रिले सर्वर से संपर्क नहीं किया गया था
नेटवर्क पैनल खोलें, लॉग सुरक्षित रखें और चेक लिंक को एक बार दबाएं। प्रयास की गई HEAD पंक्ति गंतव्य की पहचान करती है और ब्राउज़र का CORS निदान दिखा सकती है। यदि उपलब्ध हो तो प्रतिक्रिया शीर्षलेखों का निरीक्षण करें; अनुमति देने वाले हेडर की अनुपस्थिति बताती है कि पेज कोड को विज्ञापित आकार या MIME प्रकार क्यों नहीं मिला।
एक असफल जांच पहले से ही सबूत है कि वास्तविक अनुरोध का प्रयास किया गया था। चिपकाई गई URL वाली कोई ToolAcre API पंक्ति नहीं है और कोई दूसरा रिले अनुरोध नहीं है। यदि होस्ट HEAD को खराब तरीके से अनुमति देता है, तो डाउनलोड अभी भी अलग तरीके से व्यवहार कर सकता है क्योंकि यह GET का उपयोग करता है, लेकिन कोई भी पथ चुपचाप आर्किटेक्चर को स्विच नहीं करता है। कंसोल शब्दांकन ब्राउज़रों के बीच भिन्न होता है, इसलिए परिचालन रिपोर्ट के लिए एक विक्रेता के वाक्यांश पर निर्भर होने के बजाय विफल पंक्ति और हेडर साक्ष्य को सुरक्षित रखें।
टूल इसके चारों ओर रूट क्यों नहीं करता है - एक प्रॉक्सी का मतलब होगा आपके लिंक को सर्वर पर भेजना, जो कि टूल वास्तव में ऐसा नहीं करने का वादा करता है
एक प्रॉक्सी फ़ाइल सर्वर-साइड ला सकती है और ब्राउज़र के क्रॉस-ओरिजिनल रीड से बचते हुए इसे समान-मूल एंडपॉइंट से वापस कर सकती है। यह उस ऑपरेटर को लिंक और प्रत्येक रिले बाइट का भी खुलासा करेगा, बैंडविड्थ खर्च करेगा, और एक मनमानी-फ़ेच सतह बनाएगा। ToolAcre के पास जानबूझकर ऐसा कोई समापन बिंदु नहीं है।
इंटरफ़ेस द्वारा सुझाया गया फ़ॉलबैक ब्राउज़र का मूल सेव लिंक है, जहां उपलब्ध हो। वह पेज स्क्रिप्ट पढ़ने के बजाय नेविगेशन या डाउनलोड हैंडलिंग है। यह सुझाव होस्ट नीति को कमज़ोर नहीं करता है, किसी विज़िटर को प्रमाणित नहीं करता है, या किसी संरक्षित स्ट्रीम को सीधी फ़ाइल में नहीं बदल देता है। वह आर्किटेक्चरल इनकार ToolAcre को केवल ब्राउज़र इनकार को स्पष्ट सफलता में बदलने के लिए प्रतियां, एक्सेस लॉग, या आउटबाउंड-फ़ेच विशेषाधिकारों को जमा करने से रोकता है।
इसमें क्या शामिल नहीं है - CORS 403, एक लॉगिन वॉल या एक समाप्त हस्ताक्षरित URL के समान नहीं है
CORS विफलता HTTP 403 नहीं है, हालाँकि कोई भी वर्कफ़्लो को रोक सकता है। 403 एक प्रतिक्रिया स्थिति है जिसे मेज़बान ने चुना है; एक समाप्त हस्ताक्षर एक कारण बन सकता है। एक लॉगिन वॉल को उन क्रेडेंशियल्स की आवश्यकता होती है जिन्हें यह टूल छोड़ देता है। नेटवर्क आउटेज, DNS विफलता, और प्रमाणपत्र समस्याएं ब्राउज़र की सामान्य फ़ेच अस्वीकृति को साझा कर सकती हैं।
इसलिए निदान को प्रत्येक विफलता को एक लापता हेडर के रूप में मानने के बजाय नेटवर्क और कंसोल पैनल का एक साथ उपयोग करना चाहिए। जब कोई पठनीय प्रतिक्रिया आती है तो ToolAcre ज्ञात HTTP स्थितियों की रिपोर्ट करता है, लेकिन जब ब्राउज़र केवल ट्रांसपोर्ट-आकार का अपवाद प्रदान करता है तो यह अनुमान लगाने से इंकार कर देता है। इन कैटेगरी को अलग रखने से उपाय सही ढंग से निर्देशित होता है: अधिकृत सार्वजनिक वस्तु के लिए CORS को कॉन्फ़िगर करें, एक समाप्त लिंक को ताज़ा करें, प्रदाता के माध्यम से साइन इन करें, या कनेक्टिविटी ठीक करें।
टेकअवे: CORS एक होस्ट-साइड निर्णय है - कैसे डायरेक्ट मीडिया डाउनलोडर चुपचाप सर्वर पर वापस जाने के बजाय इसे ईमानदारी से रिपोर्ट करता है
CORS को मीडिया होस्ट पर नियंत्रित किया जाता है। एक ब्राउज़र-केवल डाउनलोडर उस विकल्प का पालन कर सकता है, उसे समझा सकता है और रोक सकता है; यह क्लाइंट कोड से विकल्प को ओवरराइड नहीं कर सकता। यह सीमा निश्चित रूप से असुविधाजनक है क्योंकि यह मनमाने पेजों को सार्वभौमिक क्रॉस-साइट रीडर बनने से रोकती है।
होस्ट-प्रदत्त डाउनलोड नियंत्रण का उपयोग करें, CORS-सक्षम अधिकृत फ़ाइल का अनुरोध करें, या जब उपयुक्त हो तो मूल सहेजें लिंक का उपयोग करें। डायरेक्ट मीडिया डाउनलोडर इनकार को उजागर करके और सीधे ब्राउज़र-टू-होस्ट पथ को संरक्षित करके अपना वादा निभाता है, न कि किसी सर्वर को अधिक सफल बटन के पीछे छिपाकर। इसलिए एक सफल परिणाम एक सहकारी होस्ट या एक अलग वैध ब्राउज़र सुविधा से आना चाहिए, न कि उसी अस्वीकृत पाठ को बनाए रखते हुए त्रुटि पाठ को दबाने से।