Еще раз о passport.js
Недавно мне передали на поддержку проект на express.js. При изучении кода проекта я обнаружил немного запутанную работу с аутентификацией/авторизацией которая базировалась, как и 99,999% случаев, на библиотеке passport.js. Этот код работал и следуя принципу «работет — не трогай» я оставил его как есть. Когда через пару дней мне дали задание добавить еще две стратегии авторизации. И тогда я начал вспоминать что уже делал аналогичную работу, и это занимало несколько строк кода. Полистав документацию на сайте passport.js, я почти не сдвинулся с места в понимании того, что и как нужно делать, т.к. там рассматриваись случаи когда испольуется ровно одна стратегия, для котрой, для каждой в отдельности, и даются примеры. Но как соединить несколько стратегий, зачем и когда нужно использовать метод logIn () (что то же самое, что login ()) по-прежнему не прояснялось. Поэтому, чтобы разобраться сейчас и не повторять тот же поиск еще и еще раз, — я составил для себя эти заметки.
Немного истории. Изначально веб-приложениях использовали два вида аутентификации/авторизации: 1) BASE и 2) при помощи сессий с использованием cookie. В BASE аутентификации/авторизации в каждом запросе передается некоторый заголовок, и таким образом, в каждом запросе проводится аутентификация клиента. При использовании сессий, аутентифкация клиента проводится только один раз (способы могут быть самые различные в том числе и BASE, а еще по имени и паролю, которые отправляются в форме, и еще тысячи других способов, которые в терминах passport.js называются сратегиями). Главное, что после прохождения аутентификации, клиенту в cookie сохраняется идентификатор сессии (или в некоторых реализациях данные сессии), а в данных сессии сохраняется идентификатор пользователя.
Для начала нужно определиться будете ли Вы использовать в своем приложении сессии при аутентификации/авторизации. Если Вы разрабатываете бэкэнд мобильного приложения — то, скорее всего, нет. Если это веб-приложение — то, скорее всего, да. Для использовани сессий нужно активировать cookie-parser, session middleware, а также инициализировать сессию:
const app = express();
const sessionMiddleware = session({
store: new RedisStore({client: redisClient}),
secret,
resave: true,
rolling: true,
saveUninitialized: false,
cookie: {
maxAge: 10 * 60 * 1000,
httpOnly: false,
},
});
app.use(cookieParser());
app.use(sessionMiddleware);
app.use(passport.initialize());
app.use(passport.session());
Тут нужно дать несколько важных пояснений. Если Вы не хотите, чтобы redis через пару лет работы съел всю оперативную память, нужно позаботиться о своевременном удалении даных сессии. За это отвечает параметр maxAge, который в равной степени устанавивает это значение и для cookie, и для значения сохраняемого в redis. Установка значений resave: true, rolling: true, продлевает срок действия заданным занчением maxAge при каждом новом запросе (если это нужно). В противном случае сессия клиента будет периодически прерываться. И, наконец, параметр saveUninitialized: false не будет помещать в redis пустые сессии. Это позволяет разместить инициализацию сессий и passport.js на уровне приложения, не засоряя redis лишними данными. На уровне роутов инициализацию имеет смысл размещать только в том сучае, если метод passport.initialize () необходимо вызывать с разными параметрами.
Если сессия не будет использоваться то иницализация значительно сократится:
app.use(passport.initialize());
Далее нужно создать объект стратегии (так в терминологии passport.js называют способ аутентификации). Каждая стратегия имеет свои особенности конфигрурирования. Неизменным сотается только то, что в конструктор стратегии передается callback-функция, которая формирует объект user, доступный как request.user для следующих в очереди middleware:
const jwtStrategy = new JwtStrategy(params, (payload, done) =>
UserModel.findOne({where: {id: payload.userId}})
.then((user = null) => {
done(null, user);
})
.catch((error) => {
done(error, null);
})
);
Надо хорошо представлять себе, что если не используется сессия, это метод будет вызываться при каждом обращении к защищенному ресурсу, и запрос к базе данных (как в примере) существенно скажется на производительности приложения.
Далее нужно дать команду на использование стратегии. Каждая стратегия имеет имя по умолчанию. Но его можно задать и явно, что позволяет использовать одну стратегию с разными параметрами и логикой callback-функции:
passport.use('jwt', jwtStrategy);
passport.use('simple-jwt', simpleJwtStrategy);
Далее для защищаемого роута необходимо задать стратегию аутентификации и важный параметр session (по умочанию равный true):
const authenticate = passport.authenticate('jwt', {session: false});
router.use('/hello', authenticate, (req, res) => {
res.send('hello');
});
Если сессия не используется, то защищать аутентификацией нужно все роуты с ограниченным доступом. Если же сессия используется, то аутентификация происходит однократно, и для этого задается специальный роут, например login:
const authenticate = passport.authenticate('local', {session: true});
router.post('/login', authenticate, (req, res) => {
res.send({}) ;
});
router.post('/logout', mustAuthenticated, (req, res) => {
req.logOut();
res.send({});
});
На защищаемых роутах, как правило, используется очень лаконичное middleware (которое почему-то не включено в библиотеку passport.js):
function mustAuthenticated(req, res, next) {
if (!req.isAuthenticated()) {
return res.status(HTTPStatus.UNAUTHORIZED).send({});
}
next();
}
Итак, остался один последний момент — сериализация и десериализация объекта request.user в сессию/из сессии:
passport.serializeUser((user, done) => {
done(null, user.id);
});
passport.deserializeUser((id, done) => {
UserModel.findOne({where: {id}}).then((user) => {
done(null, user);
return null;
});
});
Сериализация будет выполнена ровно один раз сразу после аутентификации. Поэтому обновить данные сохраненные в сессии будет весьма пробематично, в связи с чем сохраняется тоько идентификатор пользователя (который не меняется). Десериализация будет выполняться при каждом запросе к защищенному роуту. В связи с чем запросы к базе данных (как в примере) существенно влияют на производительность приложения.
На этом можно было бы и закончить повествование. Т.к. кроме уже сказанного, на практике ничего другого не требуется. Однако, мне пришлось по требованию разработчиков фронтенда добавить в 401 ответ объект с описанием ошибки. И это, как оказалось, не получается сделать просто. Для таких случаев нужно еще немного глубже залезть в ядро билиотеки, что не так уж и приятно. У метода passport.authenticate есть третий опциональный параметр: callback-функция с сигнатурой function (error, user, info). Небольшая проблема заключается в том, что этой функции не передается ни объект response, ни какaя-нибудь функция типа done ()/next (), в связи с чем приходится самостоятельно преобразовывать ее в middleware:
route.post('/login', authenticate('jwt', {session: false}), (req, res) => {
res.send({}) ;
});
function authenticate(strategy, options) {
return function (req, res, next) {
passport.authenticate(strategy, options, (error, user , info) => {
if (error) {
return next(error);
}
if (!user) {
return next(new TranslatableError('unauthorised', HTTPStatus.UNAUTHORIZED));
}
if (options.session) {
return req.logIn(user, (err) => {
if (err) {
return next(err);
}
return next();
});
}
req.user = user;
return next();
})(req, res, next);
};
}
Полезные ссылки:
1) toon.io/understanding-passportjs-authentication-flow
2) habr.com/post/201206
3) habr.com/company/ruvds/blog/335434
4) habr.com/post/262979
apapacy@gmail.com
4 января 2019 года
