Использование Mongo, Express, Pug и Node.js (с небольшим количеством Socket.io)
Совет для вас: если вы говорите, что работаете над «разрешениями», ни у кого нет ни малейшего представления о том, что вы делаете на самом деле. Поверьте мне, я знаю по своему опыту 😐.
Если вы новичок в разрешениях и хотите быстро понять основные типы разрешений за 5 минут, это для вас.
Разрешения
Я могу представить себе два типа разрешений, связанных с программным обеспечением: аутентификация и роли пользователей.
Аутентификация
У вас есть права доступа к этому?
По сути, разрешения для проверки подлинности — это разрешения на вход и права доступа:
- Разрешения на входвопросы о том, зарегистрировался ли пользователь и вошел/не вошел ли он в систему.
- Разрешения на доступспрашивает, имеет ли пользователь достаточно высокий уровень аутентификации для доступа к определенной информации.
С аутентификацией можно справиться довольно легко с помощью таких инструментов, как passport.js. По большей части вы можете подключить и использовать их стратегии социальной аутентификации и получить разрешения примерно через два часа (это также включает создание приложений на странице разработчика каждой социальной платформы). Для этого вам необходимо настроить приложение на уважаемой социальной платформе с URL-адресом аутентификации и URL-адресом обратного вызова.
Роли пользователей
Где вы находитесь в иерархии уровней разрешений? Вы можете просматривать, редактировать или владеть этим дерьмом?
По сути, роли пользователей определяют, что пользователям разрешено делать в данном домене:
- Обладает ли пользователь достаточными правами для выполнения этого действия?
- Обладает ли пользователь достаточными правами для изменения разрешений других пользователей?
Я рекомендую создавать собственные методы настройки, управления и проверки ролей пользователей. Например, вы можете написать функцию для установки доступных пользователю исполняемых методов списка, а затем использовать эти методы для управления данными списка, если это разрешено.
Сквош Помидор
Для Squash Tomato я уже использовал passport.js для аутентификации пользователей, но мне нужен был способ гарантировать, что пользователи не смогут выполнять функции над списками, которыми они не владели (эти списки были им предоставлены). ).
Я использую Pug для обработки шаблонов, которые отключают любой элемент, соответствующий действию, которое пользователю не разрешено выполнять, но в качестве резервной копии для пользователя, изменяющего отключенный атрибут в инструментах разработки, я хотел создать пользователя проверьте роль в моем коде.
Мое решение
- Пользователь выполняет действие.
- Выполняется функция, вызывающая конечную точку API. API содержит параметр запроса для изменяемого элемента списка, информацию, необходимую для обновления элемента списка в базе данных, и переменную разрешения.
- Если переменная разрешения имеет значение null, что означает, что этот запрос API является первым действием, предпринятым пользователем после загрузки страницы списка, переменная разрешения устанавливается с помощью функции, которая возвращает разрешение пользователя для посещенного списка.
- Если переменная разрешений содержит строковое значение, равное уровню разрешений, проверка и установка разрешений пропускаются.
- Пока разрешения действительны, контроллер выполняет действие по запросу пользователя на шаге 1.
Когда я впервые придумал это решение, контроллеры, обрабатывающие каждый запрос на внешнем интерфейсе (который вызывает конечные точки API), проверяли разрешения для каждого запроса. К черту, я прав? Производительность полностью упала бы в масштабе. Итак, я написал функцию, которая проверяет разрешения пользователя тогда и только тогда, когда разрешения еще не установлены из клиентского JavaScript (полученного из запроса API). Независимо от того, должна ли функция извлекать и устанавливать разрешения или обходить проверку, контроллер возвращает разрешения клиентскому JavaScript, который устанавливает глобальную переменную.
Это важная часть. Каждый запрос API отправляет глобальную переменную, связанную с разрешениями пользователя. Если это значение не равно нулю, функция проверки разрешений ни хрена не делает. Как это победа? Единственный раз, когда вам нужно проверять разрешения, — это самый первый запрос API при загрузке страницы, что сокращает время и потребность во всех последующих запросах (в Squash Tomato пользователь может сделать запрос API 100 раз, прежде чем перезагрузить страницу). ).
Что теперь
Чтобы правильно реализовать эту стратегию, я должен провести рефакторинг КАЖДОГО контроллера и функции, связанной с манипулированием списками. Это хорошо, особенно потому, что я также могу сделать свои клиентские функции чистыми, пока я этим занимаюсь. После рефакторинга каждой функции или метода контроллера я начну использовать WebSockets, чтобы сделать изменения интерактивными в режиме реального времени для одновременно работающих пользователей.
Дайте знать, если у вас появятся вопросы!
Следите за моим процессом разработки в твиттере @chrisjohnsoct.