Интеграция OAuth с использованием Hapi

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

Подключить

Одна из лучших частей хапи — система плагинов. Плагины позволяют сегментировать хапи-приложения в небольших портативных модулях. Почти все, что вы можете сделать с объектом hapi-сервера, вы можете сделать с помощью плагина. Вы можете добавлять маршруты, точки расширения, прослушивать события, создавать сегменты кэша; даже зарегистрировать механизм просмотра, уникальный из основного объекта сервера. Для получения дополнительной информации о плагинах, ознакомьтесь с руководством на hapijs.com.

Для этого примера мы будем использовать плагины bell и hapi-auth-cookie .

колокол

Bell — это хапи-плагин, созданный для обработки большинства утомительных рукопожатий, необходимых для интеграции со сторонними OAuth-провайдерами. Он поставляется со встроенной поддержкой наиболее часто используемых клиентов OAuth (Facebook, Twitter, GitHub и Google, и многие другие). Это означает, что большая часть тяжелой работы по интеграции OAuth с GitHub уже выполнена. Нам просто нужно настроить наш сервер hapi для его использования.

Белл обрабатывает все назад и вперед, требуемые OAuth, и будет вызывать связанную функцию обработчика hapi только после успешной аутентификации пользователя. В противном случае хапи ответит 401. Одна вещь, на которую очень важно обратить внимание, состоит в том, что у звонка нет никакой концепции пользовательского сеанса. Это означает, что после аутентификации одного запроса через третью сторону эта аутентификация будет потеряна для последующих запросов. Вы можете использовать звонок для защиты всех ваших маршрутов, но тогда каждый отдельный запрос пользователей к вашему веб-сайту потребует танца OAuth, который будет крайне неэффективным. Нам нужен способ создать безопасный cookie, который содержит информацию о сеансе OAuth, и использовать этот безопасный cookie для аутентификации будущих запросов.

хапите-Auth-печенье

hapi-auth-cookie обеспечивает простое в использовании управление сеансами cookie. Пользователи должны быть аутентифицированы другим способом; Все, что делает hapi-auth-cookie — это предоставляет API для получения и установки зашифрованных файлов cookie. У него есть несколько других служебных функций, но важно понимать, что он не выполняет никакой аутентификации сам по себе.

hapi-auth-cookie расширяет объект request hapi, добавляя методы через request.auth.session ; в частности request.auth.session.set и request.auth.session.clear . set для создания безопасного сеанса cookie и clear чтобы удалить. Эти методы добавляются в точку расширения сервера onPreAuth.

Для нашего сервера Bell будет отвечать за все переговоры OAuth и, в случае успеха, использовать hapi-auth-cookie, чтобы установить зашифрованный cookie с request.auth.session.set .

Настройка плагинов

В следующем разделе кода мы собираемся заполнить пустую функцию register и настроить два плагина для нашего сервера, который мы начали на рисунке 1.

 var Hapi = require('hapi'); var Bell = require('bell'); var AuthCookie = require('hapi-auth-cookie'); //... refer to Listing 1 server.register([Bell, AuthCookie], function (err) { if (err) { console.error(err); return process.exit(1); } var authCookieOptions = { password: 'cookie-encryption-password', //Password used for encryption cookie: 'sitepoint-auth', // Name of cookie to set isSecure: false }; server.auth.strategy('site-point-cookie', 'cookie', authCookieOptions); var bellAuthOptions = { provider: 'github', password: 'github-encryption-password', //Password used for encryption clientId: 'huU4KjEpMK4TECW',//'YourAppId', clientSecret: 'aPywVjShm4aWub7eQ3ub3FbADvTvz9',//'YourAppSecret', isSecure: false }; server.auth.strategy('github-oauth', 'bell', bellAuthOptions); server.auth.default('site-point-cookie'); //... refer to Listing 1 

Перечисление 2, Настройка плагинов bell и hapi-auth-cookie

Код Объяснение

server.register — это точка входа для добавления плагинов на сервер хапи. Он поддерживает несколько различных сигнатур функций, но для наших нужд мы передадим массив объектов. Каждый объект должен реализовывать функцию register которая будет вызываться и предоставлять текущий объект сервера хапи. Как только все плагины будут зарегистрированы, обратный вызов будет выполнен.

Нам нужно сделать небольшой обход, чтобы объяснить, как хапи обрабатывает аутентификацию. Аутентификация с помощью хапи разбита на две концепции; схемы и стратегии. Документация, здесь описывает это лучше всего:

Думайте о схеме как об общем типе аутентификации, таком как «базовый» или «дайджест». Стратегия, с другой стороны, является предварительно настроенным и именованным экземпляром схемы.

Помимо очень специфических и сложных ситуаций, вы будете использовать заранее созданные схемы и настраивать конкретную стратегию, подходящую для вашего приложения. Стратегия аутентификации будет использоваться во всем приложении для защиты ресурсов и является «экземпляром» схемы; схема является средством аутентификации запросов. И bell, и hapi-auth-cookie регистрируют новые схемы через server.auth.scheme ; схемы «колокол» и «печенье».

Имя схемы является вторым параметром для server.auth.strategy . Схема должна быть зарегистрирована на сервере хапи перед регистрацией стратегий, которые ее используют. Вот почему нам нужно сначала зарегистрировать плагины, а затем настроить стратегии через server.auth.strategy .

сайт-точка-печенье

В листинге 2 мы сначала регистрируем стратегию «cookie» и называем ее «site-point-cookie». Во всем коде мы будем ссылаться на «site-point-cookie», чтобы ссылаться на эту настроенную стратегию cookie. Полное объяснение всех доступных опций можно найти здесь . В нашем примере мы используем только password , cookie и isSecure . password должен быть надежной строкой, потому что он будет использоваться модулем железа для шифрования и дешифрования куки. cookie — это имя cookie, и isSecure устанавливает isSecure «Secure» в результирующем заголовке Set-Cookie. Это означает, что этот файл cookie будет передаваться только через HTTPS-соединения. На данный момент мы устанавливаем значение false чтобы упростить использование этого примера, но в целом это должно быть установлено в значение true .

GitHub-OAuth

Вторая и более интересная стратегия — это тип колокольчика github-oauth. Подобно регистрации «site-point-cookie», мы передаем имя, схему и объект параметров. Полный список вариантов стратегии звонка можно найти здесь . provider установлен на «GitHub», потому что Bell имеет встроенную поддержку интеграции GitHub OAuth. Он также может быть установлен на объект, если вы пытаетесь интегрироваться с поставщиком, неизвестным для звонка. password — это строка, используемая для шифрования временного файла cookie на этапах авторизации протокола. Этот файл cookie сохраняется только на этапах авторизации, после чего он уничтожается. clientId и clientSecret — это значения, которые мы создали в разделе «Начало работы». Значения в листинге 2 не будут работать, так как они являются просто случайным бредом для этого примера, вам нужно будет вставить свои собственные значения в код. Наконец, isSecure выполняет ту же функцию, что и в ‘site-point-cookie’.

Наконец, мы устанавливаем аутентификацию по умолчанию для всего сервера, чтобы использовать нашу стратегию cookie под названием «site-point-cookie». Это просто удобная настройка. Он сообщает hapi аутентифицировать запрос с помощью стратегии ‘site-point-cookie’ для каждого маршрута, добавленного с server.route . Это значительно уменьшает количество дублированных параметров конфигурации, необходимых для каждого маршрута.

Заставить это работать

Мы наконец-то закончили со всей конфигурацией и настройкой! Все, что остается, — это несколько строк логики, чтобы соединить все воедино. Как только вы увидите необходимый объем кода, вы увидите, что hapi действительно является инфраструктурой, ориентированной на конфигурацию. Давайте пройдемся по каждому из маршрутов в листинге 1 и обновим объект конфигурации и обработчик для работы.

войти в маршрут

Маршрут входа в систему — это маршрут, к которому нужно обратиться и выполнить танец OAuth с сервером GitHub. В листинге 3 показана обновленная опция конфигурации маршрута:

 method: 'GET', path: '/login', config: { auth: 'github-oauth', handler: function (request, reply) { if (request.auth.isAuthenticated) { request.auth.session.set(request.auth.credentials); return reply('Hello ' + request.auth.credentials.profile.displayName); } reply('Not logged in...').code(401); } } 

Перечисление 3 Вход в обновления маршрута

Только опция config изменилась здесь. Во-первых, мы хотим установить опцию auth ‘github-oauth’. Это значение относится к нашей стратегии «звонка», которую мы создали в листинге 2 под названием «github-oauth». Это говорит хапи использовать стратегию github-oauth при попытке аутентификации этого маршрута. Если мы опускаем эту опцию, hapi отступит и будет использовать стратегию по умолчанию, указанную в листинге 2; «Сайт-точка-печенье. Полный список доступных параметров auth выходит за рамки этой статьи, но вы можете прочитать о них здесь .

В функции-обработчике мы проверяем значение request.auth.isAuthenticated запроса. request.auth добавляется в request только на маршрутах с включенной аутентификацией. Если isAuthenticated имеет значение true, мы хотим установить cookie, указывающий на это. Помните, hapi-auth-cookie добавил объект session в request.auth с функциями set и clear . Итак, теперь, когда пользователь прошел проверку подлинности с помощью GitHub, мы хотим создать файл cookie сеанса для использования в приложении с request.auth.session.set и передать объект учетных данных, возвращенный нам из GitHub. Это создаст зашифрованный cookie с именем ‘sitepoint-auth’ в соответствии с параметрами, которые мы передали в hapi-auth-cookie. Наконец, мы хотим ответить небольшим сообщением с отображаемым именем GitHub.

Если пользователь не авторизован или отказывает в доступе к GitHub OAuth, мы ответим сообщением и кодом состояния 401.

маршрут аккаунта

Маршрут учетной записи должен отображать информацию пользователей GitHub, если они вошли в систему, а если нет, ответьте 401. Обновленный код конфигурации и обработчика приведен ниже в листинге 4.

 method: 'GET', path: '/account', config: { handler: function (request, reply) { reply(request.auth.credentials.profile); } } 

Обновления маршрута учетной записи перечисления 4

 method: 'GET', path: '/', config: { auth: { mode: 'optional' }, handler: function (request, reply) { if (request.auth.isAuthenticated) { return reply('welcome back ' + request.auth.credentials.profile.displayName); } reply('hello stranger!'); } } 

 method: 'GET', path: '/logout', config: { auth: false, handler: function (request, reply) { request.auth.session.clear(); reply.redirect('/'); } }