Приложение Rails, использующее Devise, попало в цикл перенаправления - PullRequest
Новая
       21

Приложение Rails, использующее Devise, попало в цикл перенаправления

0 голосов
/ 21 февраля 2019

У нас есть приложение rails, которое использует devise для аутентификации.Мы используем OKTA в качестве нашего IDP и используем devise_saml_authenticatable для управления аутентификацией SAML.

Мы сделали довольно небольшое обновление приложения с rails 4.2.4 -> 4.2.11, devise 3.5.6 -> 3.5.10.devise_saml_authenticatable остался на 1.2.2.Также были обновлены многие другие библиотеки.

После обновления все в приложении работало нормально, кроме этой части аутентификации.Кажется, что это происходит в бесконечном цикле перенаправленияПо сравнению с рабочей версией кажется, что все работает правильно до последнего шага, где мы видим Completed 401 Unauthorized.

  1. A Пользователь посещает веб-страницу
  2. Браузер перенаправлен наOKTA, где пользователь может войти в систему
  3. OKTA отправляет SAMLResponse в /users/saml/auth
  4. Приложение принимает пользователя правильно
  5. Мы видим Completed 401 Unauthorized in 56ms
  6. Пользователь направляется на шаг № 2, где этот цикл начинается снова.

Мы подтвердили, что шаг № 4 работает, потому что мы можем видеть новые строки пользователей в БД.Однако странно то, что current_user после этого все еще пуст.

Я добавил тестовую прокладку, подобную этой 

  before_action :my_authenticate_user!

  def my_authenticate_user!
    logger.info("AUTH USER!")
    if current_user.blank?
      logger.error("CURRENT USER IS BLANK!")
    end
    authenticate_user!
  end

И в журналах я вижу это после сообщения SAMLResponse: 

16:27:10 web.1    | D, [2019-02-20T16:27:10.223289 #51095] DEBUG -- :   User Load (0.3ms)  SELECT  "users".* FROM "users" WHERE "users"."email" = $1  ORDER BY "users"."id" ASC LIMIT 1  [["email", "XYZ@xyz.com"]]
16:27:10 web.1    | I, [2019-02-20T16:27:10.224028 #51095]  INFO -- : Setting: name, XYZ
16:27:10 web.1    | I, [2019-02-20T16:27:10.224596 #51095]  INFO -- : Setting: email, XYZ@xyz.com
16:27:10 web.1    | I, [2019-02-20T16:27:10.225235 #51095]  INFO -- : Setting: role, admin
16:27:10 web.1    | D, [2019-02-20T16:27:10.226268 #51095] DEBUG -- :    (0.2ms)  BEGIN
16:27:10 web.1    | D, [2019-02-20T16:27:10.227744 #51095] DEBUG -- :    (0.3ms)  COMMIT
16:27:10 web.1    | I, [2019-02-20T16:27:10.258703 #51095]  INFO -- : AUTH USER!
16:27:10 web.1    | E, [2019-02-20T16:27:10.259194 #51095] ERROR -- : CURRENT USER IS BLANK!
16:27:10 web.1    | I, [2019-02-20T16:27:10.261914 #51095]  INFO -- : Completed 401 Unauthorized in 74ms (ActiveRecord: 1.1ms)

В рабочей (до обновления) версии все происходит точно так же, за исключением того, что на шаге 5 аутентификация работает, и приложение продолжает свое веселье вместо перенаправления обратно в OKTA.

Фактчто отмена обновления не очень полезна для нас - обновления необходимы, поэтому цель состоит в том, чтобы попытаться исправить это с обновленными библиотеками.

Несколько вещей, которые я пробовал, но которые не помогли, такfar:

  1. Изменение session_store с active_record_store на cooke_store и ключ session_store
  2. Проверка того, что маршруты не изменились между рабочей версией и нерабочей версией (они идентичны)
  3. Подтверждено, что ничего не изменилось с OKTA, то есть сторона OKTA выглядит нормально
  4. Перемещенные пользователи (devise_for :users) маршруты к вершине tМаршрутизация пункта

То, как мы используем Devise, кажется довольно стандартным?

Мы называем authenticate_user! как before_action в ApplicationController

class ApplicationController < ActionController::Base

  if Authentication.type.disabled?
    before_action :set_guest_user
  else
    before_action :authenticate_user!
  end

Модель User имеет это 

class User < ActiveRecord::Base
  if Authentication.type.saml?
    devise :saml_authenticatable, :rememberable

И на наших маршрутах это: 

Rails.application.routes.draw do
  mount RailsAdmin::Engine => '/admin', as: 'rails_admin'
  devise_for :users

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

Любые предложения о том, как и где копаться в кишках Devise / Rails, приветствуются!

...