Facebook OAuth2 में access_token की लंबाई क्या है?

100

मैंने अपने प्रश्न का उत्तर खोजने के लिए Google और StackOverflow पर खोज की, लेकिन मुझे एक नहीं मिली।

मैं ऑफ़लाइन एक्सेस के लिए अपने डेटाबेस में access_token को संग्रहीत करना चाहता हूं और मैं अपने कॉलम की सही लंबाई निर्दिष्ट करना सुनिश्चित करना चाहता हूं।

मुझे यह भी पता नहीं चल सकता है कि यह सिर्फ एक नंबर है या संख्या और तार के बीच का मिश्रण है।

facebook oauth

— सिरिल एन।
स्रोत

128

मैं फेसबुक पर काम करता हूं और मैं इस बारे में निश्चित जवाब दे सकता हूं।

एक्सेस टोकन के लिए कृपया स्टोरेज पर अधिकतम आकार न डालें। हमें उम्मीद है कि वे समय के साथ बढ़ेंगे और सिकुड़ेंगे क्योंकि हम डेटा जोड़ते और हटाते हैं और बदलते हैं कि वे कैसे एनकोडेड हैं।

हमने 255 वर्ण होने के बारे में एक जगह मार्गदर्शन दिया। मैंने उस ब्लॉग पोस्ट को अपडेट किया है जिसमें वह जानकारी थी और आकारों के बारे में एक नोट शामिल करने के लिए हमारे नए एक्सेस टोकन डॉक्स को अपडेट किया था:

https://developers.facebook.com/docs/facebook-login/access-tokens/

गलतफहमी के लिए खेद है।

— क्रिस्टोफर ब्लिज़ार्ड
स्रोत

84

यह उचित है कि फेसबुक से निश्चित उत्तर हम बाद में इसे बदलने जा रहे हैं।

— डेव कोहेन

6

कम से कम इस तरह से मैं बदलाव की उम्मीद कर सकता हूं, इसलिए मैं बिना तैयारी के नहीं रहूंगा।

— ZeeCoder

किसी भी तरह की कोई सीमा नहीं होना एक तरह का दर्द है जैसा कि हम वर्तमान में इसे 300 बाइट varchar2 में स्टोर कर रहे हैं और आज 301-305 बाइट टोकन के साथ समस्या होने लगी है। क्या आप सुझाव दे रहे हैं कि हम इसके बजाय एक क्लोब का उपयोग करें? या क्या कुछ उचित बड़े आकार हैं जिनका हम उपयोग कर सकते हैं?

— ट्रैम्पस कर्क

मैं निश्चित रूप से उस उत्तर को अगली बार किसी से पूछता हूं "मुझे इस क्षेत्र के लिए कौन सा अधिकतम आकार निर्धारित करना चाहिए" => "किसी भी अधिकतम आकार को सेट न करें, यह वैसे भी बढ़ने वाला है"। सच में, मैं इसे प्यार करता हूँ !! फेसबुक आपने मेरा दिन बनाया;)

— क्रिस्टोफ़ फोंडिएक

7

MySQL को इस पर ऊपरी सीमा की आवश्यकता होती है। कृपया एक यथार्थवादी ऊपरी स्तर दें। जैसे 1000 वर्ण, 10,000 वर्ण, 1,000,000,000 वर्ण? कोई ऊपरी-सीमा न होना केवल अनुचित है।

— याह्या उद्दीन

70

एन्क्रिप्टेड एक्सेस टोकन के लिए फेसबुक के हालिया कदम के साथ, एक्सेस टोकन की लंबाई 255 वर्णों तक हो सकती है। यदि आप अपने डेटाबेस में एक्सेस टोकन स्टोर कर रहे हैं, तो कॉलम कम से कम varchar (255) को समायोजित करने में सक्षम होना चाहिए। यहाँ 4 अक्टूबर, 2011 से फेसबुक के डेवलपर ब्लॉग का एक अंश दिया गया है:

"एन्क्रिप्ट किए गए एक्सेस टोकन माइग्रेशन सक्षम होने के साथ, एक्सेस टोकन का प्रारूप बदल गया है। नया एक्सेस टोकन फॉर्मेट पूरी तरह से अपारदर्शी है और आपको अपने कोड में प्रारूप पर कोई निर्भरता नहीं लेनी चाहिए। एक varchar (255) फ़ील्ड पर्याप्त होगा। नए टोकन स्टोर करें। "

पूर्ण ब्लॉग पोस्ट यहाँ: https://developers.facebook.com/blog/post/572

— जॉनी ओशिका
स्रोत

2

अद्यतन जानकारी के लिए +1। यह वास्तव में अब स्वीकृत उत्तर होना चाहिए।

— डेविड बोइक

14

अब मान्य नहीं लगता। मुझे हाल ही में एक 256 वर्ण लंबाई पहुंच टोकन प्राप्त हुआ।

— o_o

2

ऊपर @o_o के समान। हम तेजी से 240+ अक्षर लंबे टोकन प्राप्त कर रहे हैं, जिसमें आजकल 255+ भी शामिल हैं।

— एरिक रेडन

वह अजीब है। 8000००० के नमूने में से, मैंने देखा सबसे लंबा १२६ अक्षर है।

— जॉनी ओशिका

1

हमने हाल ही में 344 चरित्र पहुंच टोकन देखे हैं।

— o_o

28

यह उत्तर अब सही नहीं है, और मुझे एफबी के डॉक्स में एक सही मूल्य नहीं मिल सकता है। हमें ऐसे पहुंच टोकन प्राप्त हुए हैं जो 255 वर्णों से अधिक लंबे हैं। हम भविष्य के प्रूफ की चीजों के बजाय VARCHAR से SMALLTEXT की ओर बढ़ रहे हैं।

— rodbegbie
स्रोत

हां, मुझे प्रोडक्शन ऐप में 284 कैरेक्टर मिले इसलिए मुझे कॉलम त्रुटि के कारण डेटाबेस एरर मिला (255) ...

— युकी मतसकुरा

वही। सिर्फ 12:7 पर एक 257

— लुई त्सै

1

SMALLTEXTया MEDIUMTEXT? मैंने पहले भी अपने access_token को प्रतिबंधित कर दिया थाVARCHAR(255) और मैं आज उसी के नतीजों से निपट रहा हूं।

— नोबल उत्थान

9

सेक्शन 1.4 के The OAuth 2.0 Authorization Protocol( ड्राफ्ट-आईटेफ़-ओउथ-वी 2-22 )

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

मैंने "साथी विनिर्देशों" की तलाश की, लेकिन प्रासंगिक कुछ भी नहीं मिला और धारा 11.2.2 में यह कहा गया है

o पैरामीटर नाम: access_token
o पैरामीटर उपयोग स्थान: प्राधिकरण प्रतिक्रिया, टोकन प्रतिक्रिया
o नियंत्रक बदलें: IETF
o विशिष्टता दस्तावेज़ (s): [[यह दस्तावेज़]]

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

अद्यतन: विनिर्देशन के इस लेखन का नवीनतम संस्करण ( ड्राफ्ट-आईटेफ़-ओउथ-वी 2-31 ) में एक परिशिष्ट शामिल है जो बेहतर तरीके से परिभाषित करता है कि access_token पैरामीटर से क्या उम्मीद की जाए

A.12। "access_token" सिंटेक्स
The "access_token" element is defined in Section 4.2.2 and
Section 5.1:

  access-token = 1*VSCHAR

तो अनिवार्य रूप से इसका मतलब यह है कि access_token कम से कम 1 वर्ण लंबा होना चाहिए लेकिन इस विनिर्देश में कितनी देर तक परिभाषित किया गया है इसकी कोई सीमा नहीं है।

ध्यान दें कि वे VSCHAR =% x20-7E को परिभाषित करते हैं

— जोश
स्रोत

5

फेसबुक एक्सेस टोकन 255 अक्षरों से अधिक लंबा हो सकता है। मेरे पास बहुत सी त्रुटियां थीं जैसे ActiveRecord::StatementInvalid: PG::StringDataRightTruncation: ERROR: value too long for type character varying(255)कि मूल्य फेसबुक एक्सेस टोकन था। stringटाइप कॉलम का उपयोग न करें क्योंकि इसकी लंबाई सीमित है। आप textटोकन स्टोर करने के लिए टाइप कॉलम का उपयोग कर सकते हैं ।

— palinium
स्रोत

3

हाल ही में, हमारा ऐप उन्हें 100 से अधिक अक्षरों में देख रहा है। मैं अभी भी दस्तावेज़ीकरण की तलाश कर रहा हूं ताकि मैं उनके लिए एक 'सुरक्षित' क्षेत्र का पता लगा सकूं।

— मैट मिलर
स्रोत

8

यह "दस्तावेज़ीकरण" क्या है जिसकी आप बात करते हैं? : D

— मार्क

2

मैं समय बिताने के जवाब से अपडेट करूंगा।

OAuth2 प्रलेखन से,

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

( इस दस्तावेज की धारा ४.२.२ )

नोट: फेसबुक OAuth2 का उपयोग कर रहा है, जैसा कि इस पृष्ठ पर बताया गया है ।

इसलिए अब, OAuth टोकन की लंबाई के बारे में फेसबुक के डेवलपर्स पोर्टेल पर कोई सुझाव उपलब्ध नहीं है। याहू एक 400 बिट लंबे टोकन का उपयोग करने के लिए लगता है, इसलिए यह मान लेना सबसे अच्छा है कि MySQL में एक TEXT कॉलम एक varchar की तुलना में अधिक सुरक्षित है।

— सिरिल एन।
स्रोत