Feathers: المصادقة بعد ذلك

رفض جواز السفر

بدأ هذا النقاش في # 844 وفي https://github.com/feathersjs/feathers/issues/844#issuecomment -390123148 ​​يلخص النقاط لماذا يحدث هذا. باختصار ، لم يكن هناك الكثير من التطوير في PassportJS خاصةً فيما يتعلق بدعم أطر عمل أخرى غير Express وانتقلت معظم أطر عمل HTTP الأخرى مثل Koa أو Hapi لاستخدام مكتبات مصادقة أكثر مرونة وأقل حدًا (مثل https://github.com/simov/grant لـ oAuth). اتضح أيضًا أن هناك أربعة أنواع فقط من الاستراتيجيات التي نحتاجها حقًا:

• محلي (اسم المستخدم / كلمة المرور)
• JWT
• oAuth (+ رمز وصول oAuth)
• مفتاح API

بدون الاضطرار إلى العمل مع Passport ، يمكن للريش أن يجلس بسهولة فوق أي مكتبة HTTP وأي آلية نقل أخرى (مثل MQTT أو حتى اتصالات P2P) مع فصل واضح للمخاوف وتوفير آلية مصادقة يسهل فهمها وتخصيصها.

باستخدام params.authentication

على جانب الريش ، سيكون تعيين params.authentication في مكالمة خدمة الطريقة _ الوحيدة_ لتوفير معلومات المصادقة. سيحتوي params.authentication على المعلومات اللازمة لمصادقة مكالمة الخدمة وسيكون بتنسيق مثل { strategy: 'local', email: 'email', password: 'password' } المستخدم بالفعل:

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

سيكون المتصل (مثل REST أو نقل websocket أو خطاف أو اختبار وحدة) مسؤولاً عن اجتياز 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 والتي ستحصل على طلب واستجابة Node 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 في مكالمة خدمة الطريقة _ الوحيدة_ لتقديم معلومات المصادقة.

هل يمكنك استعراض نقاط التصميم حول سبب ضرورة توفير accessToken لكل مكالمة service() ؟

ينطبق هذا فقط على الخادم وهو ما يحدث ضمنيًا بالفعل من خلال params.provider و params.headers (في حالة Websockets ، هذه فقط رؤوس وهمية) والتي يتم تعيينها لكل مكالمة خدمة بمجرد تكوين المصادقة. كان هذا يكسر فصل الريش بين الخطافات والخدمات المستقلة لبروتوكول النقل وآلية النقل الفعلية (مثل HTTP مع Express أو Socket.io) وجعل الأمر مربكًا حقًا عند تشغيل الخطاف authenticate('jwt') وما يستخدم من أجله معلومات المصادقة الخاصة به.

من ناحية سهولة الاستخدام ، لن يتغير أي شيء حقًا للمكالمات الخارجية أو الداخلية ، ولكن إذا كنت تريد الآن تشغيل الخطاف authenticate بشكل صريح على الخادم ، فيمكنك دائمًا تعيين params.authentication . هذا مهم بشكل خاص للإضافات الجديدة لإطار العمل بخلاف Express (مثل Koa أو HTTP2 أو قائمة انتظار الرسائل) التي لديها الآن طريقة موحدة لتمرير معلومات المصادقة الخاصة بها إلى آلية مصادقة Feathers.

سيستمر عميل المصادقة في تقديم طلبات مصادقة بمجرد تسجيل الدخول عن طريق استدعاء app.authenticate() .

شكرا للتوضيح. نتطلع بشدة إلى الاختبار باستخدام الإصدار 3 ، خاصة مع عملاء socket.io React Native.

سنضع بالتأكيد المعلومات حول الإصدارات المسبقة هنا. ما عليك سوى إنهاء عميل المصادقة الذي يجب أن يتعامل مع مآخذ الويب المصادق عليها بشكل أكثر موثوقية. بمجرد القيام بذلك ، سيكون من الرائع الحصول على بعض المساعدة في اختبار المصادقة الأساسية + المحلية و jwt الجديدة. يجب أن يتبع oAuth قريبًا بعد ذلك.

عندما يخرج الإصدار 3؟

أي رد على سؤالي؟

يمكنك رؤية التقدم الحالي في الفرع الرئيسي وسأقوم بنشر منشور مدونة عندما يمكن لمختبري الإصدار التجريبي تجربته. الحالة هي:

| وحدة | كود | المستندات | CLI
| --- |: ---: |: ---: | ---: |
| @ feathersjs / المصادقة | ✅ | 100٪ | ❌ |
| @ feathersjs / المصادقة المحلية | ✅ | 80٪ | ❌ |
| @ featherjs / المصادقة-oauth | ✅ | 90٪ | ❌ |
| @ feathersjs / المصادقة-العميل | ✅ | 80٪ | ❌ |

مرحبًا ، هذا رائع!

المرونة المستقبلية رائعة ، لكن ليس لدي ثقة في المصادقة في مشروع FeathersJS الخاص بي حتى الآن وأنا أمر بعملية مربكة لإنشاء ذلك.

يعني وجود تنفيذ مصادقة كامل ومُختبَر وآمن أنه يمكنني الانتقال بثقة إلى الميزات. أحد أفضل الأسباب لاستخدام MeteorJS هو أنه تكامل ممتاز للحسابات وصولاً إلى العميل.

بالنظر إلى مشكلات FeatherJS ، يدور الكثير حول المصادقة ، لذلك أنا متحمس لهذا العمل للوصول!

ما هو أفضل توثيق (أو تنفيذ مرجعي) لنظام مصادقة آمن كامل (المصادقة المحلية ، التحكم في الوصول ، رسائل البريد الإلكتروني ، إلخ) في FeathersJS اليوم؟

هذا ما لدي حتى الآن - هل هناك أي شيء أفضل؟

2018/02 - إعداد التحقق من البريد الإلكتروني في FeathersJS (إعادة صياغة مقالة 2017)
2018/02 - الريبو من المقالة أعلاه
2017/01 - كيفية إعداد التحقق من البريد الإلكتروني في FeathersJS (معطل)
2018/06 - مصادقة Vue مع Feathersjs

شكرا لك مقدما!

تم الآن إغلاق جميع المشكلات ذات الصلة وأصبح الإصدار التجريبي لـ Feathers v4 مع جميع التغييرات المقترحة التي تم تنفيذها متاحًا للاختبار. راجع دليل الترحيل للحصول على مزيد من المعلومات.