Feathers: प्रमाणीकरण अगला

पासपोर्ट बहिष्कृत करें

यह चर्चा #844 में शुरू हुई और https://github.com/phersjs/phers/issues/844#issuecomment -390123148 ​​में उन बिंदुओं का सारांश दिया गया है कि ऐसा क्यों हो रहा है। संक्षेप में, पासपोर्टजेएस में विशेष रूप से एक्सप्रेस के अलावा अन्य सहायक ढांचे के आसपास बहुत अधिक विकास नहीं हुआ है और कोआ या हापी जैसे अधिकांश अन्य HTTP ढांचे अधिक लचीले और न्यूनतम प्रमाणीकरण पुस्तकालयों (जैसे https://github.com/simov/grant) का उपयोग करने के लिए आगे बढ़े हैं। ओएथ के लिए)। यह भी पता चला कि केवल चार प्रकार की रणनीतियाँ हैं जिनकी वास्तव में आवश्यकता है:

• स्थानीय (उपयोगकर्ता नाम/पासवर्ड)
• जेडब्ल्यूटी
• oAuth (+ oAuth एक्सेस टोकन)
• एपीआई कुंजी

पासपोर्ट के आसपास काम किए बिना, पंख आसानी से किसी भी HTTP पुस्तकालय और किसी भी अन्य परिवहन तंत्र (जैसे एमक्यूटीटी या यहां तक ​​​​कि पी 2 पी कनेक्शन) के शीर्ष पर बैठ सकते हैं और एक प्रमाणीकरण तंत्र प्रदान करते हैं जो समझने और अनुकूलित करने में बहुत आसान है।

params.authentication का उपयोग करना

पंख की तरफ, सेवा कॉल में params.authentication सेट करना प्रमाणीकरण जानकारी प्रदान करने का _only_ तरीका होगा। params.authentication में सर्विस कॉल को प्रमाणित करने के लिए आवश्यक जानकारी होगी और उदाहरण के लिए { strategy: 'local', email: 'email', password: 'password' } के प्रारूप में होगी जिसका पहले से उपयोग किया जा रहा है:

// Call `find` with a given JWT
app.service('messages').find({
  authentication: {
    strategy: 'jwt',
    accessToken: 'someJWT'
  }
});

कॉलर (जैसे REST या वेबसोकेट ट्रांसपोर्ट, हुक या यूनिट टेस्ट) params.authentication पास करने के लिए जिम्मेदार होगा। इसका मतलब है कि अब कोई भ्रम नहीं होगा अगर authenticate हुक आंतरिक कॉल के लिए चलता है या नहीं या प्रमाणीकरण जानकारी वास्तव में कहां से आ रही है।

authenticate हुक

authenticate हुक मौजूद रहेगा। यह रणनीति के नामों की एक सूची लेगा और या तो

• पहली रणनीति के साथ अगले हुक पर जारी रखें जिसने कोई त्रुटि नहीं फेंकी और इसके वापसी मूल्य (नीचे देखें) को params मर्ज करें

• या सभी रणनीतियों के विफल होने पर विफल होने वाली पहली रणनीति की त्रुटि को फेंक दें

  यदि params.authentication में strategy नाम शामिल है तो केवल उस रणनीति को बुलाया जाएगा। अन्यथा सभी रणनीतियों को बुलाया जाएगा। यदि params.authentication बिल्कुल भी सेट नहीं है, तो हुक होगा

• बाहरी कॉल के लिए एक त्रुटि फेंको

• आंतरिक कॉल के लिए हमेशा की तरह जारी रखें (उदाहरण के लिए मैन्युअल रूप से params.user सेट करते समय)

app.service('messages').hooks({
  before: authenticate('jwt', 'local', 'anonymous')
});

प्रमाणीकरण रणनीतियाँ

एक बुनियादी प्रमाणीकरण रणनीति एक के साथ एक वस्तु है authenticate विधि का डेटा हो जाता है params.authentication और एक सफलता ऑब्जेक्ट या कोई त्रुटि फेंकता है तो यह सफल नहीं था:

const { Forbidden } = require('@feathersjs/errors');

const daveStrategy = {
  async authenticate (authParams) {
    const { username, password } = authParams;

    if (username === 'david' && password === 'secret') {
      return {
        user: {
          name: 'Dave',
          admin: true
        }
      };
    }

    throw new Forbidden('Not super Dave');
  }
};

app.authentication.registerStrategy('superdave', daveStrategy);

authenticate हुक में, लौटाई गई वस्तु को सेवा कॉल params में विलय कर दिया जाएगा, इसलिए यह उदाहरण params.user सेट करेगा।

रणनीतियों का विस्तार

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

class LocalStrategy {
  constructor(app);
  async findUser(authParams);
  async comparePassword(user, password);
  async authenticate (authParams);
}

class MyLocalStrategy extends LocalStrategy {
  async findUser(authParams);
}

app.authentication.registerStrategy('local', new MyLocalStrategy(app));

HTTP पार्सिंग

एक रणनीति एक parse विधि भी प्रदान कर सकती है जो मूल नोड HTTP अनुरोध और प्रतिक्रिया प्राप्त करेगी और params.authentication (या null ) के लिए मूल्य वापस करना चाहिए:

const daveStrategy = {
  async authenticate (authParams) {
    throw new Forbidden('Not super Dave');
  }

  async parse (req, res) {
    const apiKey = req.headers['x-super-dave'];

    if (apiKey) {
      return {
        strategy: 'superdave',
        apiKey
      }
    }

    return null;
  }
};

HTTP पुस्तकालय तब तय कर सकते हैं कि वे params.authentication सेट करने के लिए उन विधियों का उपयोग करते हैं या नहीं या अपने स्वयं के मिडलवेयर को प्रमाणित करते हैं।

ऐप.प्रमाणीकरण

app.authenticate(authParams, [ strategies ]) दिए गए प्रमाणीकरण मापदंडों के साथ दी गई रणनीतियों को चलाएगा:

// Will return the user for a JWT (on the server)
const { user } = app.authenticate({ accessToken }, 'jwt');

सेवा कॉल में params.authentication सेट करना प्रमाणीकरण जानकारी प्रदान करने का _only_ तरीका होगा।

क्या आप डिज़ाइन बिंदुओं के माध्यम से चल सकते हैं कि प्रत्येक service() कॉल पर accessToken प्रदान करना क्यों आवश्यक था?

यह केवल सर्वर पर लागू होता है और जो पहले से ही params.provider और params.headers माध्यम से होता है (वेबसोकेट के मामले में यह केवल नकली शीर्षलेख हैं) जो प्रमाणीकरण कॉन्फ़िगर होने के बाद प्रत्येक सेवा कॉल के लिए सेट किए जाते हैं। यह परिवहन प्रोटोकॉल स्वतंत्र हुक और सेवाओं और वास्तविक परिवहन तंत्र (जैसे एक्सप्रेस या सॉकेट के साथ HTTP) के बीच पंख अलगाव को तोड़ रहा था और इसे वास्तव में भ्रमित कर दिया जब उदाहरण के लिए authenticate('jwt') हुक वास्तव में चलता है और इसके लिए क्या उपयोग कर रहा है इसकी प्रमाणीकरण जानकारी।

उपयोगिता के अनुसार बाहरी या आंतरिक कॉल के लिए वास्तव में कुछ भी नहीं बदलेगा, लेकिन यदि आप अब सर्वर पर authenticate हुक को स्पष्ट रूप से ट्रिगर करना चाहते हैं, तो आप हमेशा params.authentication सेट कर सकते हैं। यह एक्सप्रेस के अलावा नए फ्रेमवर्क प्लगइन्स के लिए विशेष रूप से महत्वपूर्ण है (उदाहरण के लिए कोआ, एचटीटीपी 2 या मैसेजिंग कतार) जिनके पास अब अपनी प्रमाणीकरण जानकारी को पंख प्रमाणीकरण तंत्र को पारित करने का एक मानकीकृत तरीका है।

प्रमाणीकरण क्लाइंट एक बार लॉग इन करने के बाद भी app.authenticate() कॉल करके प्रमाणित अनुरोध करेगा।

स्पष्टीकरण देने के लिए धन्यवाद। v3 के साथ परीक्षण के लिए बहुत उत्सुक हैं, विशेष रूप से socket.io रिएक्ट नेटिव क्लाइंट के साथ।

पूर्व-रिलीज़ के बारे में जानकारी यहाँ अवश्य डालेंगे। प्रमाणीकरण क्लाइंट को बस लपेटना जो प्रमाणीकृत websockets को और अधिक विश्वसनीय रूप से संभालना चाहिए। एक बार ऐसा करने के बाद नए कोर + स्थानीय और जेडब्ल्यूटी प्रमाणीकरण का परीक्षण करने में कुछ मदद करना बहुत अच्छा होगा। उसके बाद जल्द ही oAuth का पालन किया जाना चाहिए।

जब संस्करण 3 बाहर आता है?

मेरे सवाल का कोई जवाब?

आप मास्टर शाखा में वर्तमान प्रगति देख सकते हैं और जब बीटा टेस्टर इसे आजमा सकते हैं तो मैं एक ब्लॉग पोस्ट डालूंगा। स्थिति है:

| मॉड्यूल | कोड | डॉक्स | सीएलआई
| --- |:---:|:---:|---:|
| @Federsjs/प्रमाणीकरण | | 100% | |
| @Federsjs/प्रमाणीकरण-स्थानीय | | 80% | |
| @फेदरजस/प्रमाणीकरण-शपथ | | 90%| |
| @फेदरजस/प्रमाणीकरण-क्लाइंट | | 80%| |

नमस्ते, यह बहुत अच्छा है!

भविष्य का लचीलापन अच्छा है, लेकिन मुझे अभी तक अपने फेदरजेएस प्रोजेक्ट में ऑथ के साथ विश्वास नहीं है और मैं इसे बनाने के लिए एक भ्रमित प्रक्रिया से गुजर रहा हूं।

एक पूर्ण, परीक्षण और सुरक्षित प्रमाणीकरण कार्यान्वयन होने का मतलब है कि मैं आत्मविश्वास से सुविधाओं पर आगे बढ़ सकता हूं। MeteorJS का उपयोग करने के सर्वोत्तम कारणों में से एक ग्राहक के लिए सभी तरह से उत्कृष्ट खातों का एकीकरण था।

फेदरजेएस मुद्दों को देखते हुए, कई प्रमाणीकरण के बारे में हैं, इसलिए मैं इस काम के लिए उत्साहित हूं!

आज FeatherJS में एक पूर्ण सुरक्षित प्रमाणीकरण प्रणाली (स्थानीय प्रमाणीकरण, अभिगम नियंत्रण, ईमेल, आदि) के लिए सबसे अच्छा दस्तावेज़ीकरण (या संदर्भ कार्यान्वयन) कहाँ है?

मेरे पास अब तक यही है - क्या कुछ बेहतर है?

2018/02 - फेदरजेएस में ईमेल सत्यापन की स्थापना (2017 लेख का पुनर्लेखन)
2018/02 - उपरोक्त लेख से रेपो
2017/01 - फेदरजेएस में ईमेल सत्यापन कैसे सेटअप करें (टूटा हुआ)
2018/06 - पंख के साथ सत्यापन प्रमाणीकरण

अग्रिम में धन्यवाद!

सभी संबंधित मुद्दों को अब बंद कर दिया गया है और सभी प्रस्तावित परिवर्तनों के साथ फेदर्स v4 के लिए पूर्व-रिलीज़ परीक्षण के लिए उपलब्ध है। अधिक जानकारी के लिए माइग्रेशन गाइड देखें।