हमारे पास VK समर्थन क्यों नहीं है

हबेरा पर हमारी पहली घोषणा के बाद, रूस से कई नए उपयोगकर्ता हमारे पास आए और सबसे अधिक अनुरोधित विशेषताओं में से एक Vkontakte समर्थन था। क्यों नहीं, क्योंकि बहुत सारे Vkontakte नेटवर्क उपयोगकर्ता हैं और अंत में इस सोशल नेटवर्क से "पसंद" करते हैं। नेटवर्किंग काम के लिए कुछ उपयोगी कर सकती है।

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

Vkontakte API के कारणों और नुकसान के बारे में पढ़ें।

OAuth, OAuth2 और अन्य

नई सेवा के लिए प्रलेखन में पहली चीज जो मैं देखता हूं, वह प्राधिकरण का प्रकार है। OAuth2 इस समय de facto मानक बन गया है और कई Likeastore- समर्थित सेवाएं इसे लागू करती हैं (केवल अंतर Twitter है, जो OAuth1 और Dribbble को लागू करता है, जो प्रोटोकॉल को बिल्कुल भी लागू नहीं करता है, लेकिन यह दादाजी लॉगिन / पासवर्ड प्रोटोकॉल का समर्थन करता है)।

जो लोग OAuth2 प्रोटोकॉल के सार से परिचित नहीं हैं, उनके लिए आप एक क्लाइंट एप्लिकेशन पंजीकृत करते हैं, जिसे उपयोगकर्ता द्वारा अधिकृत किया जा सकता है और सर्वर पर कॉलबैक के माध्यम से तथाकथित पहले एक को प्रकाशित किया जाता है। एक्सेस टोकन के लिए "एक्सचेंज" किया गया code access_token ।

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

मुझे यह देखकर खुशी हुई कि Vkontakte बिल्कुल OAuth2 प्रोटोकॉल का समर्थन करता है।

तरीके और पसंद

अगली चीज़ खोजने के तरीके थे जो आपको कस्टम "पसंद" प्राप्त करने की अनुमति देते हैं।

हमारे द्वारा समर्थित सभी अन्य एपीआई के विपरीत और आमतौर पर एक विधि है, जैसे /favorites , /likes , आदि। VKontakte उनमें से 5 (पसंदीदा उपयोगकर्ता , फ़ोटो , पोस्ट , वीडियो और लिंक ) थे। एक के बजाय 5 अनुरोध करना प्रदर्शन के लिए सबसे अच्छा विचार नहीं लग रहा था, विभिन्न तरीकों से अधिक जवाब का एक बहुत ही अलग प्रारूप था, जो सामान्य कलेक्टर वास्तुकला से थोड़ा सा बाहर हो गया।

बाद में मैंने गौर किया कि वीके तथाकथित प्रदान करता है "संग्रहीत प्रक्रियाएं" जिसमें आप सभी आवश्यक डेटा एकत्र कर सकते हैं और इसे एक HTTP अनुरोध में वापस कर सकते हैं। यह एक काम कर रहा समाधान है, लेकिन फेसबुक एपीआई बैचिंग के साथ अनुभव के बाद मुझे ऐसा नहीं लग रहा था।

हालाँकि, तरीके थे - बाकी सब तकनीक का मामला है।

आवेदन पंजीकरण और पहला अनुरोध

मैंने पहला टेस्ट स्टैंडअलोन एप्लिकेशन पंजीकृत किया और जल्द ही मेरे हाथों में access_token था। सब कुछ पुराने पैटर्न के अनुसार चला। यह उस कोड पर निर्भर था जो HTTP अनुरोध करता है और परिणाम (कनेक्टर) को पार्स करता है।

लेकिन डेटा के बजाय कंसोल में मेरी निराशा क्या थी, मैंने निम्नलिखित उत्तर देखा।

 { error: { error_code: 5, error_msg: 'User authorization failed: method is unavailable with server auth.', request_params: [ [Object], [Object], [Object], [Object], [Object] ] } } 

पहले मुझे ऐसा लगा कि एपीआई एक्सेस कोड में कुछ गड़बड़ है, लेकिन 10 बार कोड और अनुरोध URL की समीक्षा करने के बाद, मुझे एहसास हुआ कि सब कुछ ठीक था। इस मुद्दे पर Google ने बहुत कम जानकारी दी ... मैंने दस्तावेज़ीकरण में त्रुटि के विनिर्देश नहीं देखे थे, और खोज परिणाम प्राचीन मंचों में थे, जिसमें कोई जवाब नहीं था।

इस चेतावनी ने मुझे फिर से चेतावनी दी:

लेकिन अनुमति सही थी और मुझे लगा कि आवेदन स्टैंडअलोन था।

मेरी आँखों को व्यापक रूप से खोलने और ध्यान से स्टैंडअलोन अनुप्रयोगों पर प्रलेखन पढ़ने के बाद, मैंने देखा कि वे केवल ग्राहक प्रमाणीकरण का समर्थन करते हैं!

सर्वर एक के साथ अंतर यह है कि token का मूल्य response_type रूप में पारित किया गया है, और access_token के लिए "एक्सचेंजिंग" कोड के साथ कोई कदम नहीं है, क्योंकि access_token हैश पैरामीटर के रूप में पारित होने पर कॉलबैक में तुरंत मौजूद होता है, अर्थात्। केवल क्लाइंट से ही एक्सेस किया जा सकता है और सर्वर से एक्सेस नहीं किया जा सकता। क्योंकि उन दोनों को OAuth2 कहा जाता है, मैंने तुरंत इस अंतर पर ध्यान नहीं दिया।

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

और वास्तव में, क्यों?

क्या Vkontakte डेवलपर्स ने इस तरह के प्रतिबंध का परिचय दिया, और वीके एकमात्र एपीआई क्यों है जो इसे लागू करता है?

बेशक, इस प्रतिबंध को दरकिनार करने के सभी तरीके दिमाग में आते हैं (उदाहरण के लिए, क्लाइंट पर access_token को पढ़ने और सर्वर को AJAX POST करने के लिए, और उसके बाद इसका उपयोग करने के लिए स्वतंत्र है)। मुझे लगता है कि एक उत्पादक विचार मंथन के साथ कुछ और विचार पैदा हो सकते हैं, अर्थात्। विधि वास्तव में किसी भी चीज़ की रक्षा नहीं करती है, लेकिन केवल डेवलपर्स के लिए सिरदर्द जोड़ती है। लेकिन "राउंड" और "हैक्स" सभी प्रकार के नहीं हैं कि हम अपने उत्पाद का निर्माण कैसे करना चाहते हैं।

सभी छोटी चीजों के बावजूद - यह एपीआई के लिए सर्वर एक्सेस की समस्या थी जो लिकस्टोर में Vkontakte समर्थन को समाप्त कर देती है ।

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

मुझे वास्तव में उम्मीद है कि Vkontakte वेब एप्लिकेशन या कम से कम खुले सर्वर-आधारित एक्सेस के बारे में "पसंद" जैसी अपनी नीति की समीक्षा करेगा।

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