👩🏽‍🤝‍👩🏼 🈳 🗼 हम थोड़ा OpenID- प्राधिकरण लिखते हैं 👧🏼 ⛅️ 👈

भविष्य में देखो

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

व्यक्तिगत रूप से, यह प्रवृत्ति मुझे बहुत खुश करती है, और, इसके अलावा, मुझे लगभग यकीन है कि भविष्य ऐसी तकनीक में निहित है। विशेष रूप से, भविष्य में, साइटों के ढेर से जानकारी एकत्र करने के लिए नए मैशअप निश्चित रूप से दिखाई देंगे (विशेष रूप से, मैं बहुत अच्छी लेकिन गलत तरीके से भूली गई याहू पाइप्स सेवा को याद करना चाहता हूं, जो सिर्फ दिल और दिमाग नहीं जीत सकती थी क्योंकि इसका समय अभी तक नहीं आया था। । शायद अभी भी आने के लिए), और यह ठीक ऐसा "रूप कारक" है जिसे तुरंत सेवाओं के एक समूह में प्रवेश की आवश्यकता होती है।

ऐसी तकनीकों के साथ गायन की प्रशंसा करने में बहुत लंबा समय लग सकता है, लेकिन व्यक्तिगत रूप से, उदाहरण के लिए, मुझे हमेशा उन साइटों से परेशान किया गया है जिन पर मुझे कुछ डाउनलोड करने के लिए खरोंच से पंजीकरण करने की आवश्यकता होती है। आखिरकार, हम सभी ने हमेशा इस तथ्य का सामना किया कि जब आप इस या उस सामग्री को डाउनलोड करने के लिए देखते हैं, तो यह अक्सर कुछ पूरी तरह से बाईं और अयोग्य वेबसाइट पर allbooksmusicwarezzz.omgsu की भावना के नाम पर दिखाई देती है, जिसके लिए पंजीकरण की भी आवश्यकता होती है। नहीं, बात चोरी की नहीं है, तथ्य यह है कि घुटने पर बने सभी प्रकार के कबाड़ के साथ बहुत सारी साइटें हैं। लेकिन लॉगिन पासवर्ड के लिए मानव मेमोरी सीमित है, और ऐसा कुछ भी नहीं है जो आप कर सकते हैं। लेकिन यहाँ अच्छी बात यह है कि कई OpenID प्रदाता, प्राधिकरण के लिए उपयोग की जाने वाली जानकारी के अलावा, अनुरोध पर, उपयोगकर्ता के बारे में बुनियादी जानकारी प्रदान कर सकते हैं - ई-मेल, पूरा नाम, पसंदीदा भाषा, आदि। इसके अलावा, इन सेवाओं में से कई पर, आप यह नियंत्रित कर सकते हैं कि क्या देना है और क्या गुप्त रखना है। उदाहरण के लिए, यह उपयोगकर्ता के लिए सुखद नहीं होगा जब वह अगली साइट पर गया और उसने मित्रवत शिलालेख "वास्या!" देखा, शुद्ध रूसी में, और यहां तक कि प्रोफाइल, प्यारे प्यारे बिल्ली के अवतार, आदतों और उपनाम के साथ उपयोग के लिए तैयार था। ?

हम व्यापार और काम करते हैं

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

मेरे ब्लॉग के लिए, जो वर्तमान में मेरे प्रोजेक्ट्स फ़ोल्डर में चल रहा है, मैंने लॉगिन पासवर्ड के माध्यम से पंजीकरण और प्राधिकरण प्रणाली को पूरी तरह से त्यागने का फैसला किया, और केवल ओपनआईडी को छोड़ दिया। Pylons को ढांचे के रूप में चुना गया था, और ओपनो को Django परियोजनाओं के लिए पेंच करने के लिए, एक परियोजना एक सरल और समझने योग्य नाम django-openid के साथ मौजूद है। Pylons के लिए, सामान्य तौर पर, AuthKit नामक एक समाधान भी होता है, लेकिन किसी तरह मेरे पास इसके साथ बहुत अच्छे संबंध नहीं हैं, और मुझे नेटवर्क पर सभी कुछ स्निपेट मिले, जिन्हें मुझे पता लगाना था।

पहले आपको तकनीकी सहायता प्रदान करने के लिए अजगर-ओपनिड मॉड्यूल को स्थापित करने की आवश्यकता है, और फिर एक नियंत्रक (URL द्वारा अनुरोध हैंडलर, निकटतम एसोसिएशन Djangian views.py) बनाएं और संयोजन करना शुरू करें।

$ paster controller auth

तुरंत एक आरक्षण करें कि कोड उस हद तक काम कर रहा है जो प्रत्यक्ष प्रमाणीकरण प्रदान करता है, आगे क्या करना है और यह कैसे व्यवस्थित करना है यह आप पर निर्भर है, सज्जनों, रचनाकारों। शुरुआत काफी मानक है:

Copy Source | Copy HTML

OpenID.consumer.consumer से कंज्यूमर, SUCCESS, FAILURE, DiscoveryFailure आयात करें
Openid.store से आयात फ़ाइलस्टोर
खुले आयात आयात से
आयात से
हैशलीब आयात md5 से
वर्ग AuthController (BaseController):
def __before__ (स्व):
self .openid_session = session.get ( "openid_session" , {}) # देखें कि क्या openid सत्र मौजूद हैं
डीईई सूचकांक (स्व):
रिटर्न रेंडर ( '/accounts/enter.html' )
@ rest.dispatch_on (POST = "signin_POST" ) # हम सुविधा के लिए विभिन्न गेंदबाजों द्वारा GET और POST अनुरोध अलग करते हैं
डीईएन साइनइन (स्व):
if c.user: # जांचें कि यदि पहले से लॉग इन किया हुआ उपयोगकर्ता फिर से लॉग इन करने का प्रयास कर रहा है
सत्र [ 'संदेश' ] = 'पहले से ही साइन इन है।'
session.save ()
रीडायरेक्ट (url (एक्शन = 'इंडेक्स' )) # और यदि ऐसा है, तो इसे जाने न दें
session.clear ()
वापसी रेंडर ( '/index.html' )

अब हम सबसे दिलचस्प बात पर आते हैं:

Copy Source | Copy HTML

डीईएन साइनइन_पोस्ट (स्वयं):
problem_msg = 'आपके OpenID सर्वर पर कॉम्प्रोमाइज़ करने में समस्या। कृपया पुनः प्रयास करें। '
g.openid_store = filestore.FileOpenIDStore ( '।' ) # OpenID डेटा को संग्रहीत करने के लिए अस्थायी स्टोरेज बनाते हैं, जी यहां ग्लोबल वैरिएबल्स Pylons की एक सरणी है
स्वयं .consumer = उपभोक्ता ( स्वयं .openid_session, g.openid_store) # हाँ, यहाँ हमारा ग्राहक है
Openid = request.params.get ( 'ओपनिड' , कोई नहीं) # अनुरोध से OpenID पहचानकर्ता के साथ लाइन प्राप्त करें
...

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

Copy Source | Copy HTML

...
sreg_request = sreg.SRegRequest (
#required = ['ईमेल'],
वैकल्पिक = [ 'फुलनाम' , 'टाइमज़ोन' , 'भाषा' , 'ईमेल' , 'उपनाम' ]
)
अगर ओपनिड कोई नहीं है:
सत्र [ 'संदेश' ] = problem_msg
session.save ()
वापसी रेंडर ( '/index.html' )
...

यहाँ मैंने अपने आप को एक freebie की अनुमति दी और यह कोड केवल एक सरल OpenID और Google खाते से क्रॉस-लॉगिन के बीच अंतर को समझाने के लिए लिखा। तथ्य यह है कि Google उपयोगकर्ताओं को फॉर्म vasya_pupkin.google.com के ओपनआईडी पहचानकर्ता के साथ प्रस्तुत नहीं करता है, लेकिन सब कुछ बहुत सरल और अधिक मजेदार है। सभी Google उपयोगकर्ताओं के लिए प्रमाणीकरण URL बिल्कुल एक जैसा दिखता है - www.google.com/accounts/o8/id । यह उत्सुक है कि जब आप इस URL का अनुरोध करते हैं, तो Google एक तैयार-निर्मित XRDS (XML- प्रकार का दस्तावेज़ OpenID 2.0 मानक के अनुसार सर्वर द्वारा लौटाया जाता है ) देता है, जिसमें पहले से ही प्राधिकरण के लिए आवश्यक सब कुछ शामिल है, और एक उपयोगकर्ता के रूप में, आपको एक अद्वितीय आईडी असाइन किया जाता है, जो वास्तव में है , पहचानकर्ता OpenID।

Copy Source | Copy HTML

अगर Openid == 'google' :
ओपनिड = 'https://www.google.com/accounts/o8/id'
कोशिश करें :
ऑक्ट्रेक्वेस्ट = स्वयं .consumer.begin (ओपनिड) # फलक
डिस्कवरीफेल को छोड़कर , e: # क्या होगा यदि पता या ऐसे प्रदाता में कोई त्रुटि केवल आपकी कल्पना में मौजूद है?
सत्र [ 'संदेश' ] = problem_msg
session.save ()
पुनर्निर्देशित करें (url (नियंत्रक = 'सामान्य' , क्रिया = 'साइनइन' ))
difrequest.addExtension (sreg_request) # हम प्रोफ़ाइल के लिए आवश्यक फ़ील्ड निकालने के लिए SReg को कनेक्ट करते हैं
redirecturl = difrequest.redirectURL (h.url_for ( '/' , योग्य = सत्य),
return_to = h.url_for (क्रिया = 'सत्यापित' , योग्य = सत्य),
तत्काल = गलत
) # सर्वर के साथ हमारे पास जो कुछ भी था, उसके बाद हमें किसी तरह जीवित रहने की आवश्यकता है
सेशन [ 'openid_session' ] = self .openid_session
session.save ()
पुनर्निर्देशित करें (url (पुनर्निर्देशित))

खैर, अब आप सर्वर से बात कर सकते हैं कि क्या हम दोस्त बने रहेंगे।

Copy Source | Copy HTML

...
सत्यापित सत्यापित (स्व):
problem_msg = 'आपके OpenID सर्वर पर कॉम्प्रोमाइज़ करने में समस्या। कृपया पुनः प्रयास करें। '
self .consumer = उपभोक्ता ( स्वयं .openid_session, g.openid_store)
जानकारी = स्वयं .consumer.com अपूर्ण (अनुरोध.पैराम, (h.url_for (नियंत्रक = 'व्यावसायिक) )
क्रिया = 'सत्यापित' ,
योग्य = सत्य)))
if info.status == SUCCESS: # सभी एक झुंड में
sreg_response = sreg.SRegResponse.fromSuccessResponse (जानकारी) # हम SReg में अनुरोधित फ़ील्ड निकालते हैं
उपयोगकर्ता = उपयोगकर्ता (by_openid = info.identity_url) # हम डेटाबेस में पहचानकर्ता द्वारा उपयोगकर्ता की तलाश कर रहे हैं
अगर उपयोगकर्ता .exist नहीं है : # लेकिन यहाँ आप कुछ भी कर सकते हैं। उदाहरण के लिए, डेटाबेस में एक उपयोगकर्ता जोड़ें
newuser = उपयोगकर्ता ()
कोशिश करें :
ईमेल = sreg_response.get ( 'ईमेल' , u '' ),
इसके अलावा :
ईमेल = u ''
newuser.create (
ओपनिड = यूनिकोड (info.identity_url),
ईमेल = ईमेल,
पासवर्ड = यूनिकोड ( md5 (info.identity_url) .hexdigest ()),
ip = request.environ [ 'REMOTE_ADDR' ]
)
session.clear () # मैला सत्र
सत्र [ ' ओपनिड ' ] = info.identity_url
session.save ()
यदि सत्र में 'पुनर्निर्देशित_फ्रेम' :
red_url = session [ 'redirected_from' ]
डेल (सत्र [ 'पुनर्निर्देशित_फ्रेम' ])
session.save ()
पुनर्निर्देशित करें (url (red_url))
पुनर्निर्देशित करें (url (नियंत्रक = 'नीति' , क्रिया = 'सूचकांक' ))
और : # फकीर नशे में था
सत्र [ 'संदेश' ] = problem_msg
session.save ()
पुनर्निर्देशित करें (url (कार्रवाई = 'साइनइन' ))

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

मास्टर विनोग्राडिंका की तरह, मेरे सिर को एक अव्यवस्था के साथ खरोंचने के अवसर के लिए, मैं वास्तव में इस लिंक और सभी साथियों को धन्यवाद देता हूं जिन्होंने अपने स्निपेट को वहां छोड़ दिया।

UPD: मस्टैंगॉस्टैंग हैब्रयूसर AX के रहस्यों (Google से लौटी जानकारी कैसे प्राप्त करें) का खुलासा करता है, क्योंकि Google SReg को दूर नहीं करता है।

हम थोड़ा OpenID- प्राधिकरण लिखते हैं

भविष्य में देखो

हम व्यापार और काम करते हैं

More articles: