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, Feathers может легко работать поверх любой HTTP-библиотеки и любого другого транспортного механизма (например, MQTT или даже P2P-соединений) с четким разделением задач и обеспечивать механизм аутентификации, который намного проще понять и настроить.

Использование params.authentication

На стороне Feathers установка 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 или 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 .

Расширение стратегий

Стратегии аутентификации могут содержать и вызывать дополнительные методы внутри себя. Стратегии Feathers будут реализованы как классы, которые можно настроить с помощью расширения (это заменит Verifiers и в основном объединяет стратегию и Verifier в один класс):

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

app.authenticate(authParams, [ strategies ]) запустит указанные стратегии с заданными параметрами аутентификации:

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

установка params.authentication в вызове службы будет _only_ способом предоставления информации для аутентификации.

Не могли бы вы рассказать о том, почему необходимо было предоставлять accessToken при каждом вызове service() ?

Это относится только к серверу и неявно происходит уже через params.provider и params.headers (в случае веб-сокетов это только поддельные заголовки), которые устанавливаются для каждого вызова службы после настройки аутентификации. Это нарушало разделение Feathers между перехватчиками и службами, не зависящими от транспортного протокола, и фактическим транспортным механизмом (например, HTTP с Express или Socket.io) и делало это действительно запутанным, когда, например, фактически запускается перехватчик authenticate('jwt') и для чего он используется. его аутентификационная информация.

С точки зрения удобства использования ничего не изменится ни для внешних, ни для внутренних вызовов, но если теперь вы хотите явно активировать перехватчик authenticate на сервере, вы всегда можете установить params.authentication . Это особенно важно для новых плагинов фреймворка, отличных от Express (например, Koa, HTTP2 или очереди сообщений), которые теперь имеют стандартизированный способ передачи своей аутентификационной информации механизму аутентификации Feathers.

Клиент аутентификации по-прежнему будет делать аутентифицированные запросы после входа в систему, вызывая app.authenticate() .

Спасибо за разъяснение. С нетерпением жду тестирования с v3, особенно с клиентами socket.io React Native.

Обязательно выложу сюда информацию о пререлизах. Просто завершите клиент аутентификации, который должен гораздо более надежно обрабатывать аутентифицированные веб-узлы. Как только это будет сделано, было бы здорово получить некоторую помощь в тестировании новой аутентификации core + local и jwt. Вскоре после этого должен последовать oAuth.

когда выйдет 3 версия?

Есть ответ на мой вопрос?

Вы можете увидеть текущий прогресс в основной ветке, и я опубликую запись в блоге, когда бета-тестеры смогут это испытать. Статус:

| Модуль | Код | Документы | CLI
| --- |: ---: |: ---: | ---: |
| @ fersjs / аутентификация | ✅ | 100% | ❌ |
| @ Feersjs / аутентификация-локальная | ✅ | 80% | ❌ |
| @ Feerjs / Authentication-oauth | ✅ | 90% | ❌ |
| @ flesjs / клиент-аутентификации | ✅ | 80% | ❌ |

Привет, это здорово!

Будущая гибкость - это круто, но у меня пока нет уверенности в auth в моем проекте FeathersJS, и я прохожу запутанный процесс, чтобы его создать.

Наличие полной, протестированной и безопасной реализации аутентификации означает, что я могу уверенно переходить к функциям. Одной из лучших причин использовать MeteorJS была отличная интеграция учетных записей на всем пути к клиенту.

Рассматривая проблемы FeatherJS, многие из них касаются аутентификации, поэтому я очень рад, что эта работа будет реализована!

Где сегодня лучшая документация (или эталонная реализация) для полной безопасной системы аутентификации (локальная аутентификация, контроль доступа, электронная почта и т. Д.) В FeathersJS на сегодняшний день?

Это то, что у меня пока есть - есть что-нибудь лучше?

2018/02 - Настройка проверки электронной почты в FeathersJS (переработка статьи 2017 года)
2018/02 - Репо из статьи выше
2017/01 - Как настроить проверку электронной почты в FeathersJS (сломано)
2018/06 - Аутентификация Vue с Feathersjs

Заранее спасибо!

Все связанные с этим проблемы теперь закрыты, и предварительный выпуск Feathers v4 со всеми внесенными предложенными изменениями доступен для тестирования. См. Руководство по