👖 ⏳ ✂️ डर्बी सीखना 0.6 उदाहरण # 3 📼 ☸️ 👨🏽‍🚀

यह पाठ, डर्बीज पर पाठों की एक श्रृंखला की निरंतरता है - प्रतिक्रियाशील पूर्ण स्टैक फ्रेमवर्क। पहले आवश्यक पाठ पढ़ें ( पहला , दूसरा )।

इस पाठ में दो भाग शामिल होंगे: पहला डर्बी एप्लिकेशन के सर्वर साइड का अवलोकन है, और दूसरा derby-auth

मॉड्यूल ( passportjs

पर रैपर, passportjs

) का उपयोग डर्बी एप्लिकेशन में नेटवर्क के साथ-साथ पंजीकरण / प्राधिकरण के लिए भी है।

भाग 1 - डर्बी एप्लिकेशन का सर्वर कोड

ट्रेनिंग

पिछले उदाहरणों में, हमने सर्वर भाग के रूप में जानकारी की धारणा को सुविधाजनक बनाने के लिए derby-starter

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

उपयोग नहीं करेंगे।

यदि कोई व्यक्ति expressjs

परिचित नहीं है या nodejs

खराब तरीके से जानता है, तो nodejs

इलिया कांटोर के अद्भुत पाठ्यक्रम की सलाह देता nodejs

।

आधार आवेदन

आज हमारे उदाहरण के लिए एक आधार के रूप में, आपको मेरी derby-boilerplate

को कॉपी करने की आवश्यकता derby-boilerplate

। वास्तव में, यह एक न्यूनतम अनुप्रयोग है, जो हमारे पास पहले उदाहरण में था, लेकिन सर्वर हिस्सा अब derby-starter

, लेकिन परियोजना में ही (अंतिम 4 वें एक्सप्रेस का भी उपयोग किया जाता है, और redis

का उपयोग redis

नहीं किया जाता है) - अब इसके बिना संभव है)। आदेश की प्रतिलिपि बनाएँ:

 git clone https://github.com/derbyparty/derby-boilerplate.git

चलो परियोजना की संरचना की जांच करते हैं - यह पहले से ही काफी मुकाबला है, पिछले उदाहरणों के विपरीत:

 src/ app/ server/ styles/ views/ index.js

app

फ़ोल्डर में हमारा डर्बी एप्लिकेशन होगा। योजनाबद्ध रूप से, सर्वर फ़ोल्डर में derby-starter

का "एनालॉग" होगा (मैंने वास्तव में derby-starter

लिया derby-starter

, इसे वहां कॉपी किया और इसे थोड़ा कंघी किया), हम इसकी सामग्री का और अधिक विस्तार से विश्लेषण करेंगे।

क्रमशः styles

और views

फ़ोल्डर्स, शैलियों और टेम्पलेट्स में। Index.js फ़ाइल पिछले उदाहरणों में क्या थी, इसके समान है - कुछ लाइनें जो पूरी बात शुरू करती हैं।

डर्बी एप्लिकेशन का सर्वर हिस्सा

सबसे पहले, मैं आपका ध्यान एक बार फिर इस तथ्य की ओर आकर्षित करूंगा कि एक डर्बी एक expressjs

एप्लिकेशन के शीर्ष पर काम करती है, इसलिए यदि आप नहीं जानते कि यह क्या है, express-middleware

क्या है, वे कैसे काम करते हैं, सत्र कैसे काम करते हैं, राउटिंग - यहां आपको रोकना होगा और ज्ञान में अंतराल को खत्म करना।

आइए देखें कि सर्वर फ़ोल्डर में हमारे पास क्या है:

 error/ index.js server.js

मैंने त्रुटि फ़ोल्डर में एक त्रुटि हैंडलर डाला, मैं यहां नहीं रहूंगा। मैं केवल यह कह सकता हूं कि यह expressjs-middlware

, जो तब टाइप किया जाता है जब टाइप किए गए url

लिए कोई हैंडलर नहीं होता है, या एप्लिकेशन के संचालन के दौरान त्रुटियां हुई हैं। अगर आप इसे अपने लिए जानना चाहते हैं।

server.js

फ़ाइल का मुख्य उद्देश्य express

(जो सर्वर में कॉन्फ़िगर किया गया है। server.js

फ़ाइल) है और सेटिंग्स में निर्दिष्ट पोर्ट पर सर्वर server.js

:

स्रोत कोड (व्यावहारिक रूप से डर्बी-स्टार्टर से लिया गया अपरिवर्तित)

 var derby = require('derby'); exports.run = function (app, options, cb) { options = options || {}; var port = options.port || process.env.PORT || 3000; derby.run(createServer); function createServer() { if (typeof app === 'string') app = require(app); var expressApp = require('./server.js').setup(app, options); var server = require('http').createServer(expressApp); server.listen(port, function (err) { console.log('%d listening. Go to: http://localhost:%d/', process.pid, port); cb && cb(err); }); } }

इसके बाद मजेदार हिस्सा आता है, एक्सप्रेसज की स्थापना, derby

साथ। इस बिंदु को समझना यह समझने की कुंजी है कि डर्बी कैसे काम करता है।

मैं 4 वें एक्सप्रेस का उपयोग करता हूं, इसमें 3 जी से कई अंतर हैं। मुख्य बात यह है कि मानक मिडलवेयर अब express

वितरण से गायब है और इसे अलग से स्थापित किया जाना चाहिए।

तो, यह फ़ाइल बिना डर्बी के कुछ दिखेगी:

Server.js कोड, अगर हम एक नियमित एक्सप्रेस एप्लिकेशन बनाने के लिए थे:

 var express = require('express'); //  4-   middleware     //        var session = require('express-session'); //      var MongoStore = require('connect-mongo')(session); //   -      , //    var midError = require('./error'); var MongoClient = require('mongodb').MongoClient; exports.setup = function setup(app, options) { var mongoUrl = process.env.MONGO_URL || process.env.MONGOHQ_URL || 'mongodb://localhost:27017/derby-app'; //     MongoClient.connect(mongoUrl); var expressApp = express() if (options && options.static) { expressApp.use(require('serve-static')(options.static)); } expressApp.use(require('cookie-parser')()); expressApp.use(session({ secret: process.env.SESSION_SECRET || 'YOUR SECRET HERE', store: new MongoStore({url: mongoUrl}) })); //         -      //    -  404  expressApp.all('*', function(req, res, next) { next('404: ' + req.url); }); //   expressApp.use(midError()); return expressApp; }

संक्षेप में, मैं आपको याद दिलाता हूं कि यह कैसे काम करता है। सबसे पहले, मॉड्यूल जुड़े हुए हैं, फिर सबसे महत्वपूर्ण बात आती है - एक्सप्रेस middleware

(एक्सप्रेसऐप.यूज़ के माध्यम से) को expressApp.use

। वास्तव में, ये middlware

सरल कार्य हैं जिन्हें सर्वर पर आने वाले प्रत्येक अनुरोध के लिए उसी क्रम में पंजीकृत किया जाएगा। इनमें से प्रत्येक middleware

या तो प्रसंस्करण श्रृंखला को पूरा करके अनुरोध का जवाब दे सकता है (कोई नियंत्रण शेष मिडलवेयर में स्थानांतरित नहीं किया जाएगा), या अनुरोध के साथ कुछ मध्यवर्ती क्रियाएं करें (उदाहरण के लिए, cookies

पार्स cookies

, cookies

द्वारा सत्र का निर्धारण करें, आदि) और हस्तांतरण नियंत्रण। आगे श्रृंखला नीचे। middlware

कनेक्शन क्रम बहुत महत्वपूर्ण है - यह इस क्रम में है कि कार्यों को प्रत्येक अनुरोध के लिए बुलाया जाएगा।

और यहाँ डर्बी विकल्प है - डर्बी के साथ कमेंट किया हुआ server.js कोड

 // 4-  var express = require('express'); //  4-   middleware     //        var session = require('express-session'); //      var MongoStore = require('connect-mongo')(session); //   -      , //    var midError = require('./error'); var derby = require('derby'); // BrowserChannel -  socket.io   - ,  // ,        // liveDbMongo -     -     var racerBrowserChannel = require('racer-browserchannel'); var liveDbMongo = require('livedb-mongo'); //     browserify derby.use(require('racer-bundle')); exports.setup = function setup(app, options) { var mongoUrl = process.env.MONGO_URL || process.env.MONGOHQ_URL || 'mongodb://localhost:27017/derby-app'; //     (      redis) var store = derby.createStore({ db: liveDbMongo(mongoUrl + '?auto_reconnect', {safe: true}) }); var expressApp = express() //     "" // (..     /derby/...) expressApp.use(app.scripts(store)); if (options && options.static) { expressApp.use(require('serve-static')(options.static)); } //       browserchannel, //   middleware,    // (browserchannel   longpooling - ..   //    /channel) expressApp.use(racerBrowserChannel(store)); //  req   getModel,   // express-       // . createUserId expressApp.use(store.modelMiddleware()); expressApp.use(require('cookie-parser')()); expressApp.use(session({ secret: process.env.SESSION_SECRET || 'YOUR SECRET HERE', store: new MongoStore({url: mongoUrl}) })); expressApp.use(createUserId); //    -, //   ,      //   expressApp.use(app.router()); //         -     //  //    -  404  expressApp.all('*', function(req, res, next) { next('404: ' + req.url); }); //   expressApp.use(midError()); return expressApp; } //  id-     , //    id  -   function createUserId(req, res, next) { var model = req.getModel(); var userId = req.session.userId; if (!userId) userId = req.session.userId = model.id(); model.set('_session.userId', userId); next(); }

इसे जानने के लिए कुछ समय निकालें। वास्तव में, यहां मुख्य बात यह है कि browserify

का उपयोग किस लिए किया जाता है - क्लाइंट को क्लाइंट को एक तथाकथित "बंडल" देने की आवश्यकता होती है - एक डेटा ब्लॉक जिसमें डर्बी एप्लिकेशन की सभी javascript

फाइलें होती हैं, साथ ही टेम्प्लेट (cc लिपियों को यहां शामिल नहीं किया जाएगा) । आपको यह समझने की आवश्यकता है कि क्लाइंट द्वारा किसी साइट के पृष्ठ के लिए एक नियमित अनुरोध के साथ - बंडल को तुरंत ब्राउज़र में नहीं भेजा जाता है, यह बहुत महंगा होगा। शैलियों के साथ पहले से ही प्रस्तुत पृष्ठ और कुछ प्रारंभिक डेटा का सुझाव दिया गया है। यह तर्कसंगत है क्योंकि यहां गति बहुत महत्वपूर्ण है। इसके अलावा, यह पृष्ठ स्वयं "बंडल" लोड करता है - पते पर एक अनुरोध किया जाता है "/ derby /: bandle-name"।

मैंने पहले ही कहा है कि कई "डर्बी एप्लिकेशन" एक डर्बी के एक सर्वर भाग के अनुरूप हो सकते हैं - वास्तव में, उनमें से प्रत्येक का अपना बंडल होगा। यह तार्किक है। इसलिए, उदाहरण के लिए, हम साइट के क्लाइंट भाग को व्यवस्थापक पैनल से अलग कर सकते हैं ताकि सभी को अनावश्यक डेटा स्थानांतरित न करें। यदि ऐसा है, तो आपको पंजीकरण करने की आवश्यकता होगी:

  expressApp.use(clientApp.scripts(store)); expressApp.use(adminApp.scripts(store));

वही हैंडलिंग मार्गों पर लागू होता है। यदि आपके पास 2 "डर्बी एप्लिकेशन" नहीं हैं, तो हम इसके बजाय:

  expressApp.use(app.router());

दो एप्लिकेशन रूटर्स कनेक्ट करना:

  expressApp.use(clientApp.router()); expressApp.use(adminApp.router());

ठीक है, आपको यह भी समझना चाहिए कि "डर्बी एप्लिकेशन" मार्गों के हैंडलर्स के अलावा, हम अपने expressjs

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

अगला महत्वपूर्ण बिंदु browserchannel

का कनेक्शन है - यह Google socket.io

बराबर है। वास्तव में, यह एक परिवहन है, जिसके लिए वास्तविक समय में हमारा एप्लिकेशन सर्वर के साथ डेटा को सिंक्रनाइज़ करेगा। हुड के तहत यह है कि एक निश्चित समय पर क्लाइंट स्क्रिप्ट ब्राउज़रचैन को बंडल में जोड़ा जाता है, साथ ही इस मॉड्यूल से प्रसंस्करण अनुरोध (यह लॉन्गपलिंग पर आधारित है - इसलिए प्रसंस्करण की आवश्यकता है, इस मामले में /channel

)

हां, मैं यह नोट करना चाहूंगा कि मेरे मूल डर्बी सेटअप उदाहरण में, redis

का उपयोग नहीं किया गया है। हाल ही में एक डर्बी अपडेट जारी किया गया है, और अब, redis

आवश्यकता नहीं है (यह अभी भी आवश्यक है अगर हम क्षैतिज स्केलिंग करते हैं - अर्थात, प्रदर्शन को बढ़ाने के लिए, एक साथ कई डर्बी सर्वर चलाएं)।

इसलिए, इस समय आपको यह समझना चाहिए कि यह संरचना आपको हमारे आवेदन में कुछ भी लचीला जोड़ने की अनुमति देती है। यह किसी भी प्रकार के expressjs-middlware

, डर्बी प्लगइन्स, व्यक्तिगत डर्बी एप्लिकेशन, एक्सप्रेस हैंडलर - कुछ भी हो। यह सब चुपचाप एक साथ रहेंगे।

तो, ठीक है, और अंतिम बिंदु जिस पर आपको ध्यान देने की आवश्यकता है, विशेष रूप से प्राधिकरण के मुद्दे के प्रकाश में - सत्र। जैसा कि आप देख सकते हैं, डर्बी सत्र काफी express

वाले का उपयोग express

हैं। यही है, सब कुछ शास्त्रीय योजना के अनुसार होता है: पहचान के लिए एक कुकी का उपयोग किया जाता है (जो क्लाइंट के ब्राउज़र में संग्रहीत किया जाएगा), सत्र sessions

संग्रह में स्वयं को mongodb

में संग्रहीत किया जाता है।

यदि आप createUserId

फ़ंक्शन को createUserId

हैं:

 function createUserId(req, res, next) { var model = req.getModel(); var userId = req.session.userId; if (!userId) userId = req.session.userId = model.id(); model.set('_session.userId', userId); next(); }

यह देखा जा सकता है कि उपयोगकर्ता आईडी सत्र से निकाला जाता है, यदि यह अनुपस्थित है, तो आईडी अनियमित रूप से उत्पन्न होती है ( model.id()

) और _session.userId

पथ के साथ मॉडल को लिखा जाता है (यह डेटा क्रमबद्ध और ग्राहक को प्रेषित किया जाएगा) और सत्र में ही। ।

कई क्वेरी विकल्पों की कल्पना करें:

उपयोगकर्ता ने पहली बार साइट का दौरा किया और मुख्य पृष्ठ का अनुरोध किया - सर्वर पर एक नया कुकी बनाया जाएगा, एक नया सत्र (एक नया यादृच्छिक उपयोगकर्ता के साथ) - मुख्य पृष्ठ ब्राउज़र में तैयार किया गया है, और यदि हम क्लाइंट पर मॉडल को देखते हैं, तो पथ '_session.userId' पर जाएँ - हम अपनी नवगठित आईडी देखेंगे। अब हमारे आवेदन के पन्नों के चारों ओर घूमते हैं (सर्वर के लिए कोई अनुरोध नहीं होगा) - ग्राहक के पास हमेशा अपना आईडी होता है, और यदि यह सर्वर से कोई अनुरोध करता है, तो हम इसे हमेशा कुकी और सत्र द्वारा पहचान सकेंगे।
उपयोगकर्ता ने एक सप्ताह बाद पंजीकरण नहीं किया और लॉग इन किया। कुकी को उससे बचाया गया है - उसे एक ही उपयोगकर्ता दिया जाएगा - सब कुछ ठीक है।
उपयोगकर्ता दूसरे ब्राउज़र से लॉग इन करता है - चरण 1 में जैसा है

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

जब प्राधिकरण अधिक कठिन होता है, तो साइट पर जाने वाले क्लाइंट को एक यादृच्छिक आईडी प्राप्त होगी, फिर वह प्राधिकरण पृष्ठ पर जाएगा - एक उपयोगकर्ता नाम / पासवर्ड दर्ज करें, इसे सभी सर्वर पर स्थानांतरित करें, फिर सर्वर समझ जाएगा कि यह कौन है और सत्र में और _session.userId

में userId को बदलना चाहिए।

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

स्वाभाविक रूप से, हम चाहेंगे कि कोई भी ग्राहक पर इस संग्रह का हिस्सा नहीं देख सके। अब कोई समस्या नहीं है। हाल ही में, तथाकथित अनुमान डर्बी में दिखाई दिए (एक संग्रह की सदस्यता लेने की क्षमता, पूरे दस्तावेज़ की सदस्यता लेने के लिए नहीं, लेकिन केवल कुछ क्षेत्रों के लिए), लेकिन कुछ हफ़्ते पहले - यह असंभव था, और हम जिस पर विचार करेंगे, वह derby-auth

मॉड्यूल है अभी तक सक्षम नहीं है। यह उपयोगकर्ता डेटा को 2 भागों में अलग करने का उपयोग करता है: पहला auths

का एक संग्रह है (केवल निजी डेटा यहां है), दूसरा users

यहां खुले सार्वजनिक डेटा हैं। तो derby-auth

भाग 2 - एक डर्बी एप्लिकेशन में प्राधिकरण (डर्बी-ऑस्ट्रल मॉड्यूल)

डर्बी-स्थिति के बारे में थोड़ा

फिलहाल 2 पैकेज हैं - डर्बी के लिए प्राधिकरण। ये derby-auth

और derby-passport

। वे दोनों passportjs

पर रैपर हैं, (उनमें से एक, मेरी राय में, एक और कांटा)। दोनों के वर्तमान संस्करणों को डर्बी के पांचवें संस्करण के साथ उपयोग करने के लिए अभिप्रेत है (मैं अल्फा में 6 वें को याद करता हूं), अभी तक 6 के तहत अपडेट नहीं किया गया है, लेकिन यह हमें 6-के पर हमारे सभी प्रोजेक्टों में derby-auth

का उपयोग करने से नहीं रोकता है (उपलब्ध नहीं है) केवल html फॉर्म टेम्प्लेट, लेकिन हमारे साथ वे वैसे भी कस्टम हैं)।

derby-auth

पक्ष में मेरी पसंद केवल इसलिए है क्योंकि मैंने इसके साथ काम किया है।

एक और सीमा जो मैंने पहले ही उल्लेख की है कि इन दोनों परियोजनाओं में उपयोगकर्ता डेटा को दो भागों में विभाजित किया गया है। सार्वजनिक डेटा को users

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

अद्यतन

इस लेख को लिखने के कुछ दिनों बाद, व्लादिमीर माखावे (@vmakhaev) ने डर्बी- ऑर्ट के आधार पर एक भयानक डर्बी-लॉगिन प्राधिकरण मॉड्यूल विकसित किया। यह 0.6 के अंतर्गत है, अनुमानों का समर्थन करता है, इसमें पंजीकरण करने, प्रवेश करने, पासवर्ड बदलने - संक्षेप में, केवल इसका उपयोग करने के लिए तैयार घटक हैं।

वैसे, व्लादिमीर को धन्यवाद देना मत भूलना, कम से कम गीथब पर तारांकन के साथ। उन्होंने बहुत उपयोगी काम किया।

पासपोर्ट के बारे में थोड़ा सा

PassportJS

node.js

तहत प्राधिकरण के लिए middleware

यह एक अमूर्त मॉड्यूल है जो आपके एप्लिकेशन को एक लॉगिन और पासवर्ड के साथ सामान्य प्राधिकरण दोनों का उपयोग करने की अनुमति देता है, और लगभग किसी भी सेवा के माध्यम से प्राधिकरण करता है जो Oauth, Oauth 2, आदि का समर्थन करता है। प्राधिकरण। प्राधिकरण विधियों को यहां रणनीति कहा जाता है। उदाहरण के लिए, लॉगिन / पासवर्ड के माध्यम से प्राधिकरण को LocalStrategy

("स्थानीय प्राधिकरण रणनीति") GithubStrategy

है, और GithubStrategy

माध्यम से प्राधिकरण GithubStrategy

। प्रत्येक रणनीति को एक अलग मॉड्यूल में रखा गया है, इसलिए इस पूरी चीज़ को एक नोड से जोड़ना है। जेएस एप्लिकेशन कुछ इस तरह दिखाई देगा:

 var passport = require('passport'); var LocalStrategy = require('passport-local').Strategy; var GithubStrategy = require('passport-github').Strategy;

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

(या clientId

इस सामाजिक नेटवर्क में हमारे आवेदन का एक अनूठा आईडी- clientId

है) और गुप्त (कोई गुप्त कुंजी जिसे कोई किसी को नहीं बता सकता है, इसका उपयोग किया जाएगा ताकि हमारा आवेदन पुष्टि कर सके। हम ह) हैं। पंजीकरण करते समय, तथाकथित redirectURL

दर्ज करने के लिए भी आवश्यक होगा - अर्थात्, वह यूआरएल पता जहां सामाजिक है। नेटवर्क प्राधिकरण के बाद ग्राहक के ब्राउज़र को पुनर्निर्देशित करेगा। मेरे उदाहरण में, यह होगा: लोकलहोस्ट : 3000 / ऑर्टिकल / जीथब / कॉलबैक - लेकिन बाद में और भी।

नमूना आवेदन में, मैं github

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

किसी को मेरा राज मत बताना।

हमारे आवेदन से डर्बी-कनेक्ट करें

इसलिए, सबसे पहले, हम सीधे git रिपॉजिटरी से derby-auth

को डालते हैं, किसी कारण से उनके पास पिछले derby

लिए एक मास्टर संस्करण है:

npm स्थापित git: //github.com/cray0000/derby-auth#0.5 -S

Derby-auth

स्वचालित रूप से passport

और passport-local

सेट करता है, यह passport-github

स्थापित करने के लिए रहता है:

 npm install passport-github -S

अब सेटिंग्स में जाएं। हम निर्देशों के अनुसार सब कुछ करेंगे - https://github.com/lefnire/derby-auth/tree/0.5 । अधिकांश कनेक्शन क्रियाएं सर्वर पर की जाती हैं, अर्थात हमें src / server / server.js की आवश्यकता होती है।

चरण 1

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

  //  derby-auth var auth = require('derby-auth'); var strategies = { github: { strategy: require("passport-github").Strategy, conf: { clientID: 'eeb00e8fa12f5119e5e9', clientSecret: '61631bdef37fce808334c83f1336320846647115' } } }

यह स्पष्ट है कि यदि अधिक रणनीतियाँ होतीं, तो वे सभी यहाँ सूचीबद्ध होतीं:

चरण 2

विकल्प सेट करें:

  var options = { passport: { failureRedirect: '/login', successRedirect: '/' }, site: { domain: 'http://localhost:3000', name: 'Derby-auth example', email: 'admin@mysite.com' }, smtp: { service: 'Gmail', user: 'zag2art@gmail.com', pass: 'blahblahblah' } }

सिद्धांत रूप में, नामों से सब कुछ स्पष्ट है: failureRedirect

, successRedirect

- url जिसके लिए क्लाइंट को क्रमशः successRedirect

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

चरण 3

प्रारंभिक भंडारण

  auth.store(store, false, strategies);

इस कदम पर, derby-auth

डेटा एक्सेस कंट्रोल को जोड़ता है, उपयोगकर्ता ऑर्डर्स संग्रह से अन्य लोगों के रिकॉर्ड प्राप्त करने में सक्षम नहीं होगा - वह केवल अपना खाता देखेगा। दूसरा पैरामीटर वर्तमान में उपयोग में नहीं है।

चरण 4

सुनिश्चित करें कि सत्रों के भंडारण के लिए मिडलवेयर एक्सप्रेस से जुड़ा है और body-parser

(हमारे पास यह अभी तक नहीं है - स्थापित करें npm i body-parser -S

और कनेक्ट करें):

  expressApp.use(require('cookie-parser')()); expressApp.use(session({ secret: process.env.SESSION_SECRET || 'YOUR SECRET HERE', store: new MongoStore({url: mongoUrl}) })); expressApp.use(require('body-parser')()) //  method-override , //    ,  PUT   //   expressApp.use(require('method-override')())

खैर, आखिरी derby-auth middeware

बात - हम कनेक्ट करते हैं - यहाँ इस बारे में सब कुछ का एक गुच्छा अगले जुड़ा हुआ है :

 expressApp.use(auth.middleware(strategies, options));

देखते हैं कि यहां क्या होता है। यदि यह मिडलवेयर है, तो यह मान लेना तर्कसंगत है कि कुछ नियंत्रक यहां पंजीकृत हैं जो expressjs

प्रक्रिया विशेष यूआरएल के लिए अनुरोध करती है। तो यह है - यहाँ नियंत्रकों का एक सारांश है:

रोथ	विधि	मापदंडों	भाग्य
/ लॉगिन करें	`post`	उपयोगकर्ता नाम, पासवर्ड	लॉगिन और पासवर्ड का उपयोग करके लॉग इन करने के लिए कार्य करता है
/ रजिस्टर	`post`	उपयोगकर्ता नाम, ईमेल, पासवर्ड	उपयोगकर्ता नाम और पासवर्ड के साथ उपयोगकर्ता को पंजीकृत करने का कार्य करता है
/ विशेषाधिकार /: प्रदाता	`get`	अनुपस्थित हैं	यहाँ ले जाने से हम संबंधित सामाजिक के प्राधिकरण पृष्ठ पर पुनः निर्देशित हो जाएंगे। नेटवर्क। उदाहरण पथ: / स्थिति / github
/auth/:provider/callback	`get`		. — derby-auth failureRedirect successRedirect url. : /auth/github/callback — url , . .
/logout	`get`		«» '/'
/password-reset	`post`	ईमेल	email ( AJAX)
/password-change	`post`	uid, oldPassword, newPassword	( AJAX)

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

हम क्लाइंट में मॉडल में क्या देखेंगे

Derby-auth

क्लाइंट को कुछ डेटा भेजता है, जो आपको यह पता लगाने की अनुमति देता है कि क्या उपयोगकर्ता ने अपनी आईडी, लॉग इन और साथ ही साथ लॉगिंग और पंजीकरण के साथ समस्याओं का वर्णन करने वाली जानकारी का समर्थन किया है:

चलो	विवरण
_session.loggedIn	बूलियन चर - अधिकृत / अधिकृत उपयोगकर्ता नहीं
_session.userId	उपयोगकर्ता आईडी
_session.flash.error	तार की सरणी - सहायक त्रुटि संदेश (प्राधिकरण / पंजीकरण त्रुटियों के सभी प्रकार)
विशेषाधिकार। {userId} .Local	स्थानीय पंजीकरण जानकारी
विशेषाधिकार। {userId}। {प्रदाता}	प्रासंगिक सामाजिक के माध्यम से पंजीकरण डेटा। नेट

यह सब टेम्पलेट्स में उपलब्ध है और प्राधिकरण की स्थिति निर्धारित करने के लिए हमारे द्वारा उपयोग किया जाएगा।

आवेदन उदाहरण

सामान्य तौर पर, यदि दृश्य घटक derby-auth

डर्बी के 6 वें संस्करण में फिट होते हैं, तो आवेदन दो खातों में लिखा जाएगा, उनके बिना यह अधिक कठिन है। विकास को सरल बनाने के लिए, हम जुड़ेंगे bootstrap

, इसके लिए हम src / app / index.js में प्रवेश करेंगे

 app.use(require('d-bootstrap'));

पूर्व किया

 npm i d-bootstrap -S

तीसरा बूटस्ट्रैप स्थापित किया गया।

आवेदन में, मैं 2 पेज बनाऊंगा: पहला, पते के तहत "/" प्राधिकरण स्थिति के साथ, ताकि हम देख सकें कि उपयोगकर्ता आपके खाते में लॉग इन है या नहीं, साथ ही साथ क्रेडेंशियल, दूसरा, '' / लॉगिन '' प्राधिकरण पंजीकरण फार्मेसियों के साथ सीधे, प्रयोग करना। इसके अलावा, इन दो पृष्ठों में से प्रत्येक को प्रस्तुत करने से पहले, मैं संग्रह से उपयोगकर्ता क्रेडेंशियल्स खींचूंगा auths

।

मुझे लगता है कि डर्बी एप्लिकेशन फ़ाइल src/app/index.js

को विशेष टिप्पणियों की आवश्यकता नहीं है, केवल एक चीज जिसे हमने चर्चा नहीं की है वह है "*" नियंत्रक, लेकिन यह एक्सप्रेस के लिए एक मानक बात है:

 var derby = require('derby'); var app = module.exports = derby.createApp('auth', __filename); global.app = app; app.use(require('d-bootstrap')); app.loadViews (__dirname+'/../../views'); app.loadStyles(__dirname+'/../../styles'); app.get('*', function(page, model, params, next){ var user = 'auths.' + model.get('_session.userId'); model.subscribe(user, function(){ model.ref('_page.user', user); next(); }); }); app.get('/', function (page, model){ page.render('home'); }); app.get('/login', function (page, model){ page.render('login'); });

टेम्प्लेट के अनुसार, हम ऐसा करेंगे - हम इसे layout

फ़ाइल में एक मेनू के साथ करते हैं index.html

, home.html

और login.html

क्रमशः फ़ाइलों में डालते हैं, एक पृष्ठ जिसमें उपयोगकर्ता की स्थिति के बारे में जानकारी होती है (लॉग इन / लॉग इन नहीं किया जाता है, क्या जीथब खाता जुड़ा हुआ है, और प्राधिकरण / पंजीकरण वाला पृष्ठ।

तो index.html

 <import: src="./home"> <import: src="./login"> <Title:> Derby-auth example <Body:> <div class="navbar navbar-inverse" role="navigation"> <div class="container"> <div class="navbar-header"> <a class="navbar-brand" href="/">Derby-auth Example</a> </div> <div class="collapse navbar-collapse"> <ul class="nav navbar-nav"> <view name="nav-link" href="/"></view> <view name="nav-link" href="/login"></view> </ul> </div> </div> </div> {{if _session.flash.error}} <div class="container"> {{each _session.flash.error as #error}} <div class="alert alert-warning">{{#error}}</div> {{/}} </div> {{/}} <view name="{{$render.ns}}"></view> <nav-link: element="nav-link"> <li class="{{if $render.url === @href}}active{{/}}"> <a href="{{@href}}">{{@content}}</a> </li>

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

 <view name="{{$render.ns}}"></view>

इस लाइन के बजाय, डर्बी home.html

या तो कंटेंट डालेगी या login.html

, जो हमने कंट्रोलर में निर्दिष्ट किया है, उसके आधार पर: page.render('home')

या page.render('login')

सपोर्टिंग पेज के साथ home.html

:

 <index:> <div class="container"> <h1>:</h1> {{if _session.loggedIn}} <p>   </p> <h2> :</h2> {{if _page.user.local}} <p> : <b>{{_page.user.local.username}}</b></p> {{else}} <p> </p> {{/}} <h2>GitHub:</h2> {{if _page.user.github}} <p> : <b>{{_page.user.github.username}}</b></p> {{else}} <p> </p> {{/}} <a class="btn btn-danger" href="/logout"></a> {{else}} <p>    </p>  <a href="/login">/</a> {{/}} </div>

"बाहर निकलें" बटन पर ध्यान दें - नियंत्रक का उपयोग यहां किया गया है। GET /logout derby-auth

हम बहुत अधिक परेशान नहीं करेंगे और बूटस्ट्रैप वेबसाइट से सीधे शैलियों के साथ लॉगिन फॉर्म ले लेंगे, "साइन इन" http:// getbootstrap-examples/signin/ का एक उत्कृष्ट उदाहरण है

स्टाइल्स को बूटस्ट्रैप उदाहरण से कॉपी किया गया है - slyles / index.styl फ़ाइल

 .form-signin { max-width: 330px; padding: 15px; margin: 0 auto; } .form-signin .form-signin-heading, .form-signin .checkbox { margin-bottom: 10px; } .form-signin .checkbox { font-weight: normal; } .form-signin .form-control { position: relative; height: auto; -webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box; padding: 10px; font-size: 16px; } .form-signin .form-control:focus { z-index: 2; } .form-signin input[type="email"] { margin-bottom: -1px; border-bottom-right-radius: 0; border-bottom-left-radius: 0; } .form-signin input[type="password"] { margin-bottom: 10px; border-top-left-radius: 0; border-top-right-radius: 0; }

प्राधिकरण और पंजीकरण के साथ Login.html फ़ाइल:

 <index:> <view name="signin"></view> <hr/> <view name="signup"></view> <signin:> <div class="container"> <form class="form-signin" role="form" action='/login' method='post'> <h3 class="form-signin-heading"></h3> <input name="username" type="text" class="form-control" placeholder="" required="" autofocus=""> <input name="password" type="password" class="form-control" placeholder="" required=""> <button class="btn btn-lg btn-primary btn-block" type="submit"></button> <br/> <a class="btn btn-lg btn-danger btn-block" href="/auth/github"> GitHub</a> </form> </div> <signup:> <div class="container"> <form class="form-signin" role="form" action='/register' method='post'> <h3 class="form-signin-heading"></h3> <input name="username" type="text" class="form-control" placeholder="" required="" autofocus=""> <input name="email" type="email" class="form-control" placeholder="" required=""> <input name="password" type="password" class="form-control" placeholder="" required=""> <button class="btn btn-lg btn-primary btn-block" type="submit"></button> </form> </div>

यदि आप शुरू करते हैं तो सब कुछ कुछ इस तरह दिखाई देगा:

मैंने हमारे डर्बी-ऑर्थोरिक नियंत्रणों के आधार पर बटस्टैप फॉर्म को थोड़ा बदल दिया। हम पंजीकरण फॉर्म में क्या ध्यान देते हैं: यह पोस्ट फॉर्म है जो एक्शन / लॉगिन की ओर ले जाता है - डर्बी-ओर्ट इसे प्रोसेस करेगा, यूजरनेम और पासवर्ड फील्ड नाम सभी हमारी प्लेट से हैं। GitHub के माध्यम से लॉग इन - वहाँ से भी / / गीथब - के लिए एक अनुरोध प्राप्त करें।

पंजीकरण फार्म। समान चीज़ - पोस्ट / रजिस्टर, फ़ील्ड: उपयोगकर्ता नाम, ईमेल, पासवर्ड।

हम आवेदन शुरू करते हैं: npm शुरू - स्थिति देखें - "उपयोगकर्ता लॉग इन नहीं है", रजिस्टर करें, देखें - "सिस्टम में उपयोगकर्ता"। हम आउटपुट - / लॉगआउट कर सकते हैं। जब तक हम बाहर नहीं निकलते हैं, तब तक हमारे पास जीथब खाते को चालू खाते में बाँधने का अवसर होता है, इसके लिए हमें "जीथब के माध्यम से लॉग इन" पर क्लिक करना होगा, हम जीथब पर पुनर्निर्देशित हो जाएंगे, हम वहाँ लॉग इन करेंगे, सब कुछ पक्का करेंगे और साइट पर वापस जाएँगे।

डर्बी-ओर्ट भी एक स्थानीय रणनीति के माध्यम से पंजीकरण किए बिना, सामाजिक खातों के माध्यम से साइट पर पंजीकरण करने की अनुमति देता है। नेटवर्क।मैं हब पर उपयोग की जाने वाली तकनीक को पसंद करता हूं, जब केवल पंजीकृत उपयोगकर्ता ही सामाजिक खातों को अपने खाते में बाँध सकता है। नेटवर्क, लेकिन इसके लिए डर्बी-ऑर्ट के लिए थोड़ा ट्वीक की जरूरत होगी।

जो हुआ उसके साथ खेलो। डेवलपर कंसोल का उपयोग करके उपलब्ध डेटा देखें (कंसोल में app.model.get () दर्ज करें)।

मैं माफी मांगता हूं कि हमने शेष चिप्स को उदाहरण में लागू नहीं किया derby-auth

(पासवर्ड को रीसेट करना और बदलना) - यह सबक डर्बी के सर्वर भाग को समझाने की आवश्यकता के कारण पहले से ही काफी बड़ा था।

हमने सरलीकृत रूपों को भी लागू किया है, यहाँ बिंदु यह है कि एक पूर्ण अनुप्रयोग में, इन ब्लॉकों को अलग-अलग घटकों में निकाला जाएगा, लेकिन हमने अभी तक उनका अध्ययन नहीं किया है। गितुब

पर अंतिम संस्करण

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

पुनश्च

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

पी पी एस

वैसे, डर्बी 0.6 अल्फा 7 पहले ही जारी किया जा चुका है - अंतिम रिलीज करीब और करीब हो रही है।

आप derbyjs की तरह है - मुसीबत नहीं लेते पर एक स्टार डाल करने के लिए GitHub

डर्बी सीखना 0.6 उदाहरण # 3