Использование Mongo, Express, Pug и Node.js (с небольшим количеством Socket.io)

Совет для вас: если вы говорите, что работаете над «разрешениями», ни у кого нет ни малейшего представления о том, что вы делаете на самом деле. Поверьте мне, я знаю по своему опыту 😐.

Если вы новичок в разрешениях и хотите быстро понять основные типы разрешений за 5 минут, это для вас.

Разрешения

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

Аутентификация

У вас есть права доступа к этому?

По сути, разрешения для проверки подлинности — это разрешения на вход и права доступа:

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

С аутентификацией можно справиться довольно легко с помощью таких инструментов, как passport.js. По большей части вы можете подключить и использовать их стратегии социальной аутентификации и получить разрешения примерно через два часа (это также включает создание приложений на странице разработчика каждой социальной платформы). Для этого вам необходимо настроить приложение на уважаемой социальной платформе с URL-адресом аутентификации и URL-адресом обратного вызова.

Роли пользователей

Где вы находитесь в иерархии уровней разрешений? Вы можете просматривать, редактировать или владеть этим дерьмом?

По сути, роли пользователей определяют, что пользователям разрешено делать в данном домене:

  • Обладает ли пользователь достаточными правами для выполнения этого действия?
  • Обладает ли пользователь достаточными правами для изменения разрешений других пользователей?

Я рекомендую создавать собственные методы настройки, управления и проверки ролей пользователей. Например, вы можете написать функцию для установки доступных пользователю исполняемых методов списка, а затем использовать эти методы для управления данными списка, если это разрешено.

Сквош Помидор

Для Squash Tomato я уже использовал passport.js для аутентификации пользователей, но мне нужен был способ гарантировать, что пользователи не смогут выполнять функции над списками, которыми они не владели (эти списки были им предоставлены). ).

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

Мое решение

  1. Пользователь выполняет действие.
  2. Выполняется функция, вызывающая конечную точку API. API содержит параметр запроса для изменяемого элемента списка, информацию, необходимую для обновления элемента списка в базе данных, и переменную разрешения.
  3. Если переменная разрешения имеет значение null, что означает, что этот запрос API является первым действием, предпринятым пользователем после загрузки страницы списка, переменная разрешения устанавливается с помощью функции, которая возвращает разрешение пользователя для посещенного списка.
  4. Если переменная разрешений содержит строковое значение, равное уровню разрешений, проверка и установка разрешений пропускаются.
  5. Пока разрешения действительны, контроллер выполняет действие по запросу пользователя на шаге 1.

Когда я впервые придумал это решение, контроллеры, обрабатывающие каждый запрос на внешнем интерфейсе (который вызывает конечные точки API), проверяли разрешения для каждого запроса. К черту, я прав? Производительность полностью упала бы в масштабе. Итак, я написал функцию, которая проверяет разрешения пользователя тогда и только тогда, когда разрешения еще не установлены из клиентского JavaScript (полученного из запроса API). Независимо от того, должна ли функция извлекать и устанавливать разрешения или обходить проверку, контроллер возвращает разрешения клиентскому JavaScript, который устанавливает глобальную переменную.

Это важная часть. Каждый запрос API отправляет глобальную переменную, связанную с разрешениями пользователя. Если это значение не равно нулю, функция проверки разрешений ни хрена не делает. Как это победа? Единственный раз, когда вам нужно проверять разрешения, — это самый первый запрос API при загрузке страницы, что сокращает время и потребность во всех последующих запросах (в Squash Tomato пользователь может сделать запрос API 100 раз, прежде чем перезагрузить страницу). ).

Что теперь

Чтобы правильно реализовать эту стратегию, я должен провести рефакторинг КАЖДОГО контроллера и функции, связанной с манипулированием списками. Это хорошо, особенно потому, что я также могу сделать свои клиентские функции чистыми, пока я этим занимаюсь. После рефакторинга каждой функции или метода контроллера я начну использовать WebSockets, чтобы сделать изменения интерактивными в режиме реального времени для одновременно работающих пользователей.

Дайте знать, если у вас появятся вопросы!

Следите за моим процессом разработки в твиттере @chrisjohnsoct.