2013-08-23 8 views
10

मैं restify.js के साथ एक रीस्टफुल एपीआई बनाने की कोशिश कर रहा हूं, लेकिन मैं एपीआई को सभी को बेनकाब नहीं करना चाहता हूं। और मैं टोकन-आधारित प्रमाणीकरण का उपयोग करने जा रहा हूं। मेरे दिमाग में प्रक्रिया इस तरह है, मुझे यकीन नहीं है कि यह उचित है या नहीं।restify.js के लिए टोकन-आधारित प्रमाणीकरण को लागू करने का सबसे अच्छा तरीका क्या है?

  1. उपयोगकर्ता टोकन प्राप्त करने के लिए एपीआई को उपयोगकर्ता नाम/पासवर्ड भेजता है।

  2. यह टोकन हर दूसरे एपीआई के कॉल के अनुरोध में शामिल किया जाना चाहिए।

यदि यह उचित है, तो क्या कोई node.js लाइब्रेरी मैं उपयोग कर सकता हूं?

इसके अतिरिक्त, मैं टोकन की रक्षा कैसे करूं? अगर कोई टोकन के साथ http अनुरोध को रोकता है, तो उस व्यक्ति को एपीआई यूआरएल और टोकन मिल जाएगा। फिर वह अनुरोध भेज सकता है जैसा वह चाहता है। इससे बचने का कोई रास्ता है क्या?

बहुत बहुत धन्यवाद!

+0

यदि आप https का उपयोग कर सकते हैं तो आप इस तरह के मध्य-व्यक्ति हमले की समस्याओं में शामिल नहीं होंगे। जब तक आप http पर हैं टोकन समझौता किया जा रहा है। – Chandu

+0

धन्यवाद। मैंने सुना है कि https का उपयोग करने से कुछ प्रदर्शन ट्रेडऑफ होगा। क्या यह एकमात्र समाधान है? और मेरे दूसरे प्रश्न के संबंध में, क्या node.js में टोकन-आधारित प्रमाणीकरण के लिए एक मौजूदा लाइब्रेरी है? धन्यवाद! – user2440712

+0

http://passportjs.org/ यह oauth – Chandu

उत्तर

24

Basic access authentication

Restify एक authorizationParser प्लगइन के साथ आता है। authorizationParserAuthorization पर पार्सर। जब प्लगइन उपयोग में है, तो यह req.username और req.authorization गुण उपलब्ध कराएगा। बाद के प्रारूप है:

{ 
    scheme: <Basic|Signature|...>, 
    credentials: <Undecoded value of header>, 
    basic: { 
    username: $user 
    password: $password 
    } 
} 

आपके सर्वर चुनिंदा अनुरोध करता है कि प्रमाणीकरण की आवश्यकता रोकना और उपयोगकर्ता पहुँच क्रेडेंशियल्स को सत्यापित करने की आवश्यकता होगी।

यहाँ एक उदाहरण सर्वर है कि सभी कॉल के लिए प्रमाणीकरण की आवश्यकता होगी:

var restify = require('restify'), 
    server; 

server = restify.createServer(); 

server.use(restify.authorizationParser()); 

server.use(function (req, res, next) { 
    var users; 

    // if (/* some condition determining whether the resource requires authentication */) { 
    // return next(); 
    // } 

    users = { 
     foo: { 
      id: 1, 
      password: 'bar' 
     } 
    }; 

    // Ensure that user is not anonymous; and 
    // That user exists; and 
    // That user password matches the record in the database. 
    if (req.username == 'anonymous' || !users[req.username] || req.authorization.basic.password !== users[req.username].password) { 
     // Respond with { code: 'NotAuthorized', message: '' } 
     next(new restify.NotAuthorizedError()); 
    } else { 
     next(); 
    } 

    next(); 
}); 

server.get('/ping', function (req, res, next) { 
    res.send('pong'); 

    next(); 
}); 

server.listen(8080); 

परीक्षण करने के लिए सबसे आसान तरीका उपयोग कर रहा है कर्ल:

$ curl -isu foo:bar http://127.0.0.1:8080/ping 

HTTP/1.1 200 OK 
Content-Type: application/json 
Content-Length: 6 
Date: Fri, 12 Dec 2014 10:52:17 GMT 
Connection: keep-alive 

"pong" 

$ curl -isu foo:baz http://127.0.0.1:8080/ping 

HTTP/1.1 403 Forbidden 
Content-Type: application/json 
Content-Length: 37 
Date: Fri, 12 Dec 2014 10:52:31 GMT 
Connection: keep-alive 

{"code":"NotAuthorized","message":""} 

Restify इनबिल्ट JsonClient बुनियादी प्रमाणीकरण का समर्थन करता है कि के साथ आता है, जैसे

var restify = require('restify'), 
    client; 

client = restify.createJsonClient({ 
    url: 'http://127.0.0.1:8080' 
}); 

client.basicAuth('foo', 'bar'); 

client.get('/ping', function(err, req, res, obj) { 
    console.log(obj); 
}); 

OAuth 2.0

आप टोकन प्रमाणीकरण पसंद करते हैं, तो आप restify-oauth2 पैकेज कि Client Credentials प्रमाणीकरण प्रवाह को लागू करता है, है जो आप के बाद कर रहे हैं का उपयोग कर सकते हैं।

प्रलेखन पृष्ठ प्रत्येक एंडपॉइंट की भूमिका सहित, इस तरह के प्रमाणीकरण को सेटअप करने के चरण-दर-चरण का वर्णन करता है, और code example उनके भंडार में है।

सारांश

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

साइड नोट।उत्पादन में, यदि असुरक्षित चैनल पर कम-से-कम एक बार स्थानांतरित किया जाता है, तो क्रेडेंशियल को "समझौता" माना जाना चाहिए, उदा। एसएसएल बग के मामले में, जैसे Heartbleed के मामले में समझौता एचटीटीपीएस।

+0

के लिए समर्थन है जैसे आकर्षण, – Steven

+0

'req.username'' req.authorization.basic.username' को सही करना चाहिए। –

+0

कुछ तरीकों को प्रमाणित करने के लिए मैं इस विधि को कैसे लागू करूं लेकिन दूसरों तक पहुंच की इजाजत देता हूं? –

संबंधित मुद्दे

 संबंधित मुद्दे