क्लाइंट पर "दुर्भावनापूर्ण" कोड का क्रॉस-ब्राउज़र लॉन्च

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

मेरी टीम वेतन की गणना के लिए एक ऑनलाइन सेवा विकसित कर रही है। हमें क्लाइंट की निजी कुंजी के साथ रिपोर्टिंग स्टेटमेंट पर हस्ताक्षर करने के कार्य के साथ सामना करना पड़ा, इसलिए, हमें उस कोड को निष्पादित करने की आवश्यकता है जो क्लाइंट की मशीन पर ब्राउज़र के दृष्टिकोण से खतरनाक है। उसी समय, मैं वास्तव में हमारी सेवा का उपयोग करने के लिए एक ब्राउज़र चुनने में ग्राहक को सीमित नहीं करना चाहता था।

इस तरह से हमने इसे हल किया है न कि सबसे तुच्छ कार्य।

इसलिए, हमें क्लाइंट मशीन पर काफी असुरक्षित कोड चलाने की आवश्यकता है। बेशक, कोई भी हमें ऐसा नहीं करने देगा, लेकिन आशा ने हमें नहीं छोड़ा कि पर्याप्त संख्या में प्रश्न क्या आप सुनिश्चित हैं? ”और“ क्या आप इस साइट पर भरोसा करते हैं? ”हमारा विचार पारित होगा।

प्रवेश द्वार पर, हमारे पास एक काम करने वाली ActiveX लाइब्रेरी थी जो हमें जरूरत की हर चीज देती थी, लेकिन केवल IE में। हमें एक क्रॉस-ब्राउज़र समाधान की आवश्यकता थी।

हम "क्रॉस-ब्राउज़र" शब्द की हमारी समझ के बारे में तुरंत आरक्षण कर देंगे। आंकड़ों के अनुसार, हमारे उपयोगकर्ता निम्न ब्राउज़रों का उपयोग करते हैं:



IE 8+ (39%)
मोज़िला फ़ायरफ़ॉक्स 3.6+ (19%)
ओपेरा 9+ (17%)
क्रोम (14%)
IE 7 (6%)
IE 6 (4%)
सफारी 5+ (1%)

तदनुसार, हमें इन सभी ब्राउज़रों में सही संचालन की आवश्यकता है।

समाधान बहुत जल्दी आ गया। यह विचार यह है: उपयोगकर्ता मशीन पर एक छोटा प्रोग्राम स्थापित करता है जो हमारे द्वारा आवश्यक कार्यों को कर सकता है। इसके साथ सहभागिता HTTP अनुरोधों का उपयोग करके की जा सकती है। कार्यक्रम वास्तव में छोटा हो गया, वह एक विशेष प्रकार के आने वाले अनुरोधों को स्वीकार करने और संबंधित क्रिप्टोकरंसी विधियों को चलाने में सक्षम था।

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

CORS

पहले दृष्टिकोण के रूप में, हमने सबसे सरल उपलब्ध विधि - क्रॉस-ओरिजिन रिसोर्स शेयरिंग का उपयोग करने का निर्णय लिया। यह तकनीक कई आधुनिक ब्राउज़रों द्वारा समर्थित है और इसे लागू करना आसान है। लेकिन, दुर्भाग्य से, यह ओपेरा द्वारा समर्थित नहीं है, और IE में इसके कार्यान्वयन से इंटरनेट और इंट्रानेट श्रेणियों में स्थानीय कॉल करना संभव नहीं है। और अगर हम अभी भी उत्तरार्द्ध के साथ रख सकते हैं (हमारे पास स्टॉक में हमारे ActiveX घटक थे), तो हमने ओपेरा समर्थन का त्याग नहीं किया। ओपेरा के लिए एक एक्सटेंशन लिखने का विचार जो सही पते से स्थानीय कॉल को प्रॉक्सी करेगा, इंटरफ़ेस विशेषज्ञों द्वारा हतोत्साहित किया गया था - और हम खुद यह सुनिश्चित नहीं कर रहे थे कि सभी उपयोगकर्ता यह पता लगाएंगे कि एक्सटेंशन कैसे स्थापित किया जाए। इसके अलावा, इसे समय पर अपडेट भी करना होगा ... मुझे अन्य समाधानों की तलाश करनी होगी।

फ़्लैश

हमारा अगला विचार क्रॉस-डोमेन प्रश्नों के लिए flXHR लाइब्रेरी का उपयोग करना था। लेकिन इस रास्ते के साथ हम फिर से सुरक्षा नीतियों के कारण दुबके हुए थे, इस बार खुद ही चमक गए। इससे पहले कि हमारे पास केवल GET अनुरोधों का उपयोग करने के लिए हमारी सेवा को फिर से लिखने का समय था (https से http तक POST अनुरोधों पर प्रतिबंध को रोकने के लिए), यह पता चला कि इंटरनेट और इंट्रानेट क्षेत्रों से प्राप्त फ्लैश अनुप्रयोगों को उपयोगकर्ता की मशीन से पृथक सैंडबॉक्स में रखा गया था HTTP- अनुरोधों सहित। फिर से अतीत।

JSONP

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

iframe

अगला प्रयोग आइफ्रेम को 127.0.0.1 पर खोलना है और किसी तरह इसके साथ संवाद करना है। और फिर से ओपेरा की सुरक्षा ने हमें विफल कर दिया। ओपेरा की सुरक्षा नीतियों के इन गुणों ने हमारे विचार को समाप्त करने की धमकी दी। यह पता चला कि उपयोगकर्ता की मशीन में क्रॉस-डोमेन एक्सेस के दौरान, स्क्रिप्ट जोड़ने, रीडायरेक्ट को जोड़ने और iframes में खोलने के लिए, ओपेरा एक प्रतिक्रिया के बजाय एक ओपेरा: crossnetworkwarning सेवा पृष्ठ रखता है, जिसमें उपयोगकर्ता स्थानीय मशीन पर स्विच करने की अपनी इच्छा की पुष्टि कर सकता है (स्वाभाविक रूप से, जब स्क्रिप्ट लोड हो रही है स्थानीय मशीन से, इस पृष्ठ का उपयोगकर्ता नहीं देखेगा और कुछ भी पुष्टि नहीं कर सकता है)। एकमात्र अपवाद तब होता है जब उपयोगकर्ता द्वारा संक्रमण स्पष्ट रूप से किया जाता है (उदाहरण के लिए, <a href="http://localhost/" target="my_frame"> लिंक पर क्लिक करके)।

आईफ्रेम + पोस्टमासेज

यह पता चला है कि किसी भी तरह से नहीं, लेकिन स्थानीय पते वाले आइफ्रेम को खोला जा सकता है। लेकिन फिर आप पोस्टमैसेज के माध्यम से स्थानीय सर्वर से भी संवाद कर सकते हैं! यह केवल यह चुनना है कि स्थानीय फ्रेम को कैसे खोला जाए। दो संभावनाएं हैं, वास्तव में: या तो उपयोगकर्ता को एक लिंक दिखाएं जो एक छिपे हुए फ्रेम में स्थानीय पते पर संक्रमण का प्रदर्शन करेगा, या स्वयं संक्रमण करेगा और उपयोगकर्ता को स्वतंत्र रूप से संक्रमण की अनुमति देगा। हिचकिचाहट के बाद, हमने दूसरा रास्ता चुना। इसका लाभ यह है कि ओपेरा पर: crossnetworkwarning पृष्ठ (जैसा कि स्क्रीनशॉट में देखा जा सकता है), एक विशिष्ट डोमेन के लिए रिज़ॉल्यूशन को याद रखना संभव है, परिणामस्वरूप, उपयोगकर्ता से केवल एक बार अतिरिक्त कार्रवाई की आवश्यकता होगी। इसके अलावा, यह विधि आपको उपयोगकर्ता के हस्तक्षेप के बिना सेवा तक पहुंचने के प्रयास को दोहराने की अनुमति देती है, इस मामले में जब यह स्थापित नहीं है या शुरू नहीं हुआ है, और सेवा उपलब्ध होते ही आवश्यक विधि शुरू करें।

परिणाम

आईई 6-7 और फ़ायरफ़ॉक्स 3 में पोस्टमैसेज काम नहीं करता है, लेकिन हमने इस मामले के लिए ला-हैश-पोलिंग बैसाखी नहीं जोड़ने का फैसला किया है। IE उपयोगकर्ताओं के लिए, हमने ActiveX घटक को छोड़ दिया, और फ़ायरफ़ॉक्स 3 उपयोगकर्ताओं (जिनमें से हमारे पास केवल कुछ हैं) के लिए, हमने बाद के संस्करणों में अपडेट करने का प्रस्ताव करने का निर्णय लिया।

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