Тем временем у Derby появился свой хаб.
Ну а сегодня мы поговорим об авторизации и ограничении доступа к данным. Что лучше использовать everyauth или passport? Сложно ли добавить авторизацию? Как ограничивать доступ к данным? Как разделить приложение для пользователей и админку в рамках одного derby-приложения?
Авторизация
В derby-examples есть пример приложения с авторизацией на everyauth. Как вы можете видеть, довольно легко реализовать авторизацию через twitter, facebook, linkedin, github и т.п. Но у связки derby + everyauth есть определенные проблемы с авторизацией через логин-пароль, связанные с тем, что everyauth сильно привязан к express. Хотя everyauth написал один из создателей derby (задолго до derby), использование этого модуля именно для derby не совсем удобно. В жизни так бывает. По этому рекомендация — использовать passport, который в силу своей архитектуры лучше вписывается в derby. Для большинства случаев вы можете использовать derby-auth, который представляет из себя уже готовый модуль авторизации, реализованный на passport. Как вы можете видеть в нем создаются две коллекции: auth — где находятся пароли пользователей и users — где находятся остальные данные пользоватлей. Почему две коллекции? В derby в данный момент нету возможности ограничивать доступ к полям сущности (entity — объект в бд с ид). Только ко всей сущности сразу или ко всей коллекции. Это связано с ограничениями в share.js. То есть в рамках одной коллекции users, мы не можем разрешить пользователю видеть имена других пользователей, и в то же время, не видеть их паролей. По этому нам нужно две коллекции. Это, пожалуй, самый неприятный момент в данное время в derby и конечно же будет исправлен в будущем.
Ограничение доступа к данным
Мы можем ограничивать доступ к данным на уровне базы данных (точнее сказать на уровне orm или объекта store) с помощью модуля racer-access. В нем вы можете использовать сессии от connect для идентификации пользователей. Используется примерно так:
var racerAccess = require('racer-access');
derby.use(racerAccess);
store.allow('change', 'users', function (some usefull arguments) {
return true || false;
});
derby.use — так добавляются плагины в derby.
store.allow — так мы задаем правила ограничения доступа к данным. В данном случае правило для изменения коллекции users. Возвращаемые аргументы различаются в зависимости от правил и содержат, в том числе, и connect сессию. Функция возвращает bool — разрешен доступ или нет.
Документации по racer-access нету, но исходники небольшие, читаемые и содержат комментарии.
Клиентские приложения
Мы сделали авторизацию и ограничили доступ к данным. Но что если мы не хотим отправлять в браузер пользователя темплейты, стили и логику от админки? Мы можем разбить наше клиентское приложение на несколько. Здесь есть пример двух клиентских приложений — app и login. А это — они же в виде объектов на сервере.
login = require('../login')
main = require('../app')
Темплейты, стили и js для них будут соответственно в папках /views/app — /views/login, /styles/app — /styles/login, /lib/app — /lib/login. В браузер будет загружаться либо одно, либо другое приложение. Это удобно не только с точки зрения безопасности, но и с точки зрения уменьшения трафика.
Материалы по Derby
UPDATE: Подсказали что еще есть derby-passport, сделанный по мотивам derby-auth
