Twitter प्राधिकरण या STTwitter लाइब्रेरी के साथ एक दिन कैसे मारना है

प्रस्तावना

एक दिन को मारना वास्तविक है, विशेष रूप से उदाहरण की तुलना में सबसे तेज ट्विटर प्राधिकरण पर विचार करना, वही facebook।

तुलना के लिए, प्राधिकरण प्राप्त करने के लिए एल्गोरिथ्म:



चहचहाना

टोकन प्राप्त होता है -> मैं इस टोकन का उपयोग करता हूं हम लॉगिन पृष्ठ पर जाते हैं -> हम उपयोगकर्ता प्राधिकरण की प्रतीक्षा कर रहे हैं और कॉलबैक_url द्वारा एक नया टोकन प्राप्त करते हैं -> एक गुप्त टोकन के लिए टोकन का आदान-प्रदान करते हैं।



फेसबुक

हम calback_url पैरामीटर और अन्य विकल्पों के साथ facebook लॉगिन पेज खोलते हैं -> हम प्राधिकरण की प्रतीक्षा कर रहे हैं और कॉलबैक पर हमें पहले से ही एक गुप्त टोकन मिलता है जिसका उपयोग किया जा सकता है।



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



लेकिन मैं विशेष रूप से ट्विटर के बारे में बात करना चाहता था, क्योंकि जैसा कि मैंने ऊपर कहा था - ट्विटर के पास oAuth1 / 2 प्रदान करने वाले अन्य सामाजिक नेटवर्क की तुलना में केवल भारी मात्रा में नुकसान है



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

चरण 1 2 के साथ

पहला कदम पहला टोकन प्राप्त करना है, जो आमतौर पर स्पष्ट नहीं है कि इसकी आवश्यकता क्यों है। ठीक है, ठीक है, सिस्टम के खिलाफ कोई बहस नहीं। यहां सब कुछ सरल है, आपको एप्लिकेशन डेटा (एपीआई कुंजी) और चेकसम के अनुसार पोस्ट अनुरोध में प्राधिकरण भेजने की आवश्यकता है।

थोड़ा आगे चलना: प्राप्त टोकन का उपयोग करके, हमें एक लिंक बनाना होगा जहां हम उपयोगकर्ता को भेजते हैं। उपयोगकर्ता को खोने के लिए नहीं (उसे आवेदन को छोड़ने से रोकने के लिए), कोई इसे बहुत सरलता से कर सकता है: सफारी खोलें, और फिर आवेदन के लिए कॉलबैक_यूरल और कस्टम यूआरएल योजनाएं (उदाहरण के लिए, myappscheme: // paradesult) आवेदन पर वापस जाएं और ट्विटर द्वारा प्रेषित मापदंडों को zaparspit करें। और अब वह पहला नुकसान है - ट्विटर कस्टम यूआरएल योजनाओं को पंजीकृत करने की अनुमति नहीं देता है। इस वजह से, इस तरह की स्कीम का उपयोग करके एप्लिकेशन पर लौटना असंभव हो जाता है। कैसे हो? आपको एक कस्टम UIWebView बनाना होगा और webView प्रतिनिधि विधि का उपयोग करके एक ठंडा पकड़ना चाहिए: shouldStartLoadWithRequest: इंटरसेप्ट और हमारे UIWebView के डाउनलोड लिंक की जाँच करें। अब यह कॉलबैक को किसी तरह का अवास्तविक डोमेन बनाने के लिए बना हुआ है (जो वैसे भी लोड नहीं होगा, या पहले से ही वास्तविक में बदल जाएगा, बस अगर आवेदन में साइट है) जैसे getmetothewounderlandandfeedmewitharainbownpinkunicorn.com

जैसे ही विधि यह देखती है कि वेब दृश्य को इस डोमेन को लोड करने की आज्ञा मिली है, हम इसके कार्य को पूरा करते हैं और टोकन के लिए मापदंडों को पार्स करते हैं।

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

STTwitter पुस्तकालय के साथ, यह बस किया जाता है:



तुरंत आलसी इनिशियलाइज़ेशन, जो मैंने एक पुराने बूढ़े सेनफोर्ड से सीखा है: डी (जो जानता है कि वह समझ जाएगा)। मैंने सभी अतिरिक्त भूसी को काट दिया जैसे सिस्टम में आंतरिक लेखांकन के लिए जाँच करना, आदि।

// api  oauth -     twitterEngine -(STTwitterOAuth *)oauth { if (!_oauth) { _oauth = [STTwitterOAuth twitterOAuthWithConsumerName:@"APP_NAME" consumerKey:TWI_API_KEY consumerSecret:TWI_API_SECREET]; } return _oauth; } -(STTwitterAPI *)api { if (!_api) { if ([twitterEngine isAuthorized]) { NSLog(@"Full access account"); _api = [STTwitterAPI twitterAPIWithOAuthConsumerKey:TWI_API_KEY consumerSecret:TWI_API_SECREET oauthToken:[[NSUserDefaults standardUserDefaults] valueForKey:TWI_STORE_AUTH_TOKEN] oauthTokenSecret:[[NSUserDefaults standardUserDefaults] valueForKey:TWI_STORE_AUTH_SECRET]]; } else { NSLog(@"App only client"); _api = [STTwitterAPI twitterAPIAppOnlyWithConsumerName:IN_APP_NAME consumerKey:TWI_API_KEY consumerSecret:TWI_API_SECREET]; } } return _api; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

नियंत्रक का एक सा:

 - (IBAction)loinTwitterButtonClicked:(id)sender { twitter = [twitterEngine new]; // twitterEngine          twitter if ([twitterEngine isAuthorized]) { // handling authorized } else { twitter.delegate = self; [twitter sendRequestToken]; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

वर्ग:

 -(void)sendRequestToken { [self.oauth postTokenRequest:^(NSURL *url, NSString *oauthToken) { [self.delegate openWebViewWithUrl:url]; //     url    UIWebVew } oauthCallback:@"http://getmetothewounderlandandfeedmewitharainbownearpinkunicorns.com" errorBlock:^(NSError *error) { // handling error }]; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

और फिर नियंत्रक (यहां प्रोटोकॉल विधि, और UIWebView से प्रतिनिधि जो लोड किए गए URL को स्वीकार करता है

 -(void) openWebViewWithUrl:(NSURL *)url { //              // UIWebView *browser = [[UIWebView alloc] initWithFrame:CGRectMake(0, 20, self.view.frame.size.width, self.view.frame.size.height - 20)]; NSURLRequest *request = [NSURLRequest requestWithURL:url]; [browser loadRequest:request]; [browser setDelegate:self]; [self.view addSubview:browser]; } -(BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType { NSURL *url = [request URL]; NSLog(@"Loading URL: %@", [url absoluteString]); if ([[url host] isEqualToString:@"getmetothewounderlandandfeedmewitharainbownearpinkunicorns.com"]) { [webView removeFromSuperview]; //      NSDictionary *params = [twitterEngine parseURLToParams:url]; [twitter sendAccessToken:[params objectForKey:@"oauth_verifier"]]; //        3     . return NO; //   NO        ,     . } return YES; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

चरण 3

और आखिरी अभियान। इस विषय पर एसटीटी पुस्तकालय (अंतिम चरण) का अध्ययन करने के लिए मैंने सबसे अधिक समय की हत्या की और समाधान कुछ पंक्तियों के रूप में निकला। लेकिन, जैसा कि मैं चाहता था, मैंने मुख्य चीज से परहेज किया, चेकसम के साथ उपद्रव किया और हेडर से सब कुछ कनेक्ट किया। मैं यह भी ध्यान देना चाहता हूं कि ट्विटर से oAuth1 की सुस्तता के कारण, oauth_verifier टोकन का आदान-प्रदान हेडर (!!!) के माध्यम से नहीं होता है जैसा कि पिछले चरणों में किया गया था, लेकिन नामांकित व्यक्ति का शरीर स्वयं अनुरोध करता है। यहां एसटीटी ने पहिए में एक छड़ी चिपका दी। जैसा कि यह निकला, एसटीटी के पास प्राधिकरण योजना के माध्यम से काम करने के लिए एक सीधा उपकरण नहीं है जिसे मैंने चुना है, अर्थात्, इसमें oauth_token_secret के लिए oauth_verifier का आदान-प्रदान करने की कोई विधि नहीं है। मुझे गहराई में जाना पड़ा और सुपरक्लास के बहुत गहरे तरीकों का उपयोग करना पड़ा, जो कि संक्षेप में भेजने की लगभग एक सरल प्रणाली विधि थी। थोड़ा पीछे हटते हुए - मैं http प्रोटोकॉल जानता हूं, मुझे पता है कि कैसे, लेकिन यह मेरे लिए पर्याप्त समय में सॉकेट के साथ छेड़छाड़ करने के लिए पर्याप्त था ताकि मैं प्रोटोकॉल के साथ इस तरह के निचले स्तर के काम से नफरत करूं। यदि आप मध्य स्तर की प्रोग्रामिंग (यूआई नहीं बल्कि प्रत्यक्ष प्रोटोकॉल नहीं) कह सकते हैं तो यह मेरे करीब है। लेकिन पीछे मुड़कर नहीं देखा गया था, और मैं अपने अतिरिक्त तरीके को लिखने के लिए तैयार था, जो टोकन एक्सचेंज को लागू करता है। भगवान किसी और के कोड में तल्लीन करते हैं, और यहां तक ​​कि इसे जोड़ते हैं, मेरे लिए यह एक वास्तविक दुःस्वप्न है, अगर केवल इसलिए कि यह मुझे नहीं लिखा था जिसने इसे लिखा था। लेकिन कहीं नहीं जाना था ... एक दोस्त के रूप में, मैंने एक परिचित समय चर @ "oauth_verifier" देखा और तुरंत उस विधि का अध्ययन करना शुरू कर दिया जहां यह देखा गया था। वास्तव में, मुझे अभी भी पता नहीं है कि मैंने इस कुंजी द्वारा खोज का उपयोग करने का अनुमान क्यों नहीं लगाया। मैं कुछ घंटे बचा लेता।

क्या निकला: ट्विटर पर एक पिन प्राधिकरण है। यह योजना समान है, लेकिन इसे केवल उन अनुप्रयोगों के लिए लागू किया जाता है, जिनके अंदर मैं कॉलबैक नहीं कर सकता और इस तरह से एक्सचेंज के लिए टोकन प्राप्त कर सकता हूं। वास्तव में, इस योजना में पिन एक सरलीकृत है (ठीक है, इसे धिक्कार है, साइट से 8 अंक याद रखें और आवेदन में दर्ज करें?) विनिमय के लिए टोकन। और चूंकि मैंने कभी भी पिन द्वारा प्राधिकरण योजना का अध्ययन नहीं किया (और फिर भी यह दो पैराग्राफों में ट्विटर ज्ञान के आधार पर प्रलेखित है), मुझे नहीं पता था कि उनके पास एक तंत्र था। सौभाग्य से, मैंने अपनी पद्धति को इसी तरह बुलाने का फैसला किया



PostAccessTokenRequestWithPIN: successBlock: errorBlock:



यह एसटीटी पुस्तकालय की बहुत ही विधि है जो अनिवार्य रूप से लागू की गई है जो मुझे चाहिए। कीस्ट्रोक्स की एक जोड़ी और हमें twitterEngine वर्ग की अंतिम विधि मिलती है जो गुप्त टोकन के लिए टोकन के आदान-प्रदान को लागू करता है और बाद में पुनर्प्राप्ति के लिए इसे जेब में लिखता है:

 -(void)sendAccessToken:(NSString *)oauth_verifier { [self.oauth postAccessTokenRequestWithPIN:oauth_verifier successBlock:^(NSString *oauthToken, NSString *oauthTokenSecret, NSString *userID, NSString *screenName) { [[NSUserDefaults standardUserDefaults] setObject:oauthToken forKey:TWI_STORE_AUTH_TOKEN]; [[NSUserDefaults standardUserDefaults] setObject:oauthTokenSecret forKey:TWI_STORE_AUTH_SECRET]; [[NSUserDefaults standardUserDefaults] synchronize]; } errorBlock:^(NSError *error) { // handling error }];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

निष्कर्ष

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