Блог

Главная - Вопросы по программированию - Дизайн авторизации в приложении Mongoose / Express

Дизайн авторизации в приложении Mongoose / Express

#mongodb #express #mongoose #authorization

#mongodb #экспресс #mongoose #авторизация

Вопрос:

Я работаю над приложением mongoose / express, в котором документ необходимо загрузить из базы данных, прежде чем определять, разрешено ли пользователю выполнять с ним какие-либо действия. Например, пользователь может иметь read права доступа к документу, но только если этот документ имеет определенное значение в своем organizations поле. Или пользователь может редактировать документ, но только если его идентификатор пользователя находится в assignedTo массиве в этом документе.

Каковы плюсы и минусы следующих подходов к проектированию в приложении mongoose / express?

A: авторизация в промежуточном программном обеспечении, запросы к базе данных несколько раз:

  1. Пользователь проходит проверку подлинности в промежуточном программном обеспечении, и объект пользовательских разрешений извлекается из объекта сеанса пользователя.
  2. Промежуточное программное обеспечение авторизации запрашивает в базе данных документ, к которому обращается пользователь. На основе объекта разрешений пользователя и значений в документе определяется, разрешено ли пользователю выполнять действие.
  3. Маршрут пересылает запрос контроллеру, который загружает документ mongoose, выполняет логику приложения, обновляет базу данных и отправляет ответ обратно пользователю.

B: авторизация в промежуточном программном обеспечении, прикрепляет документ к запросу:

  1. Пользователь проходит проверку подлинности в промежуточном программном обеспечении, и объект пользовательских разрешений извлекается из объекта сеанса пользователя.
  2. Промежуточное программное обеспечение загружает документ из базы данных и определяет, авторизован ли пользователь для выполнения действия. Затем промежуточное программное обеспечение присоединяет документ mongoose к запросу.
  3. Маршрут пересылает запрос контроллеру, который выполняет логику приложения и обновляет базу данных, используя документ mongoose, прикрепленный к запросу.

C: выполнить авторизацию на уровне контроллера / служб:

  1. Пользователь проходит проверку подлинности в промежуточном программном обеспечении, и объект разрешений извлекается из объекта сеанса пользователя.
  2. Маршрут пересылает запрос контроллеру, который загружает документ mongoose из базы данных, проверяет, авторизован ли пользователь для выполнения действия. Если это так, контроллер выполняет логику приложения и обновляет базу данных.

Подход A вписывается в парадигму проектирования промежуточного программного обеспечения, но запрашивает базу данных несколько раз. Недостатки потенциально могут быть смягчены путем индексации коллекций со всеми необходимыми полями для авторизации, чтобы покрыть запрос. Подход B, похоже, нарушает базовый принцип проектирования MVC, передавая модель через запрос. Подход C не имеет ни одного из вышеперечисленных недостатков, но, похоже, требует более шаблонного кода, записанного на уровне контроллера / служб.

Я знаю, что есть и другие потенциальные подходы, которые я здесь не рассматривал, особенно если вы разрешаете использовать другие сервисы, такие как кеши Redis.

Комментарии:

1. Мы решили это с помощью ‘B’. Это был самый простой подход. Наше промежуточное программное обеспечение выглядело как loadDocument, checkPermissions, view , или loadDocument, checkPermissions, edit

2. Шаг первый, поместите authz в службу, затем вы можете вызывать службу откуда угодно — из промежуточного программного обеспечения, контроллера или какого-либо другого приложения, обращающегося к вашей модели, у которой нет промежуточного программного обеспечения или контроллеров.