Рельсы - Разработайте и Act_as_audited

Question

Эй, я хочу использовать Devise и acts_as_audited вместе, но когда я пытаюсь связать их, используя -

class ApplicationController < ActionController::Base
 audit Candidate
 protected

 def current_user
   @user = User.find(user_session)    
 end

Я получаю эту ошибку.

stack level too deep

Нужно ли делать это по-другому?

Спасибо

Answer 1

Это старый вопрос, но все еще поднимает свою уродливую голову.Вот другой, возможно, более подходящий обходной путь, который сработал для меня.

Сначала, как другие описывают, ошибка возникает при использовании audited (ранее Act_as_audited) с devise (и, возможно, других драгоценных камней аутентификации), а затем, когда выАудит любого из столбцов, которые Devise использует в вашей пользовательской модели (last_sign_in_at, last_sign_in_ip и т. д.).

1. Devise пытается аутентифицировать пользователя (используя его authenticate_user! before_filter).
2. Devise пытается обновить / сохранить информацию для входа пользователя (last_sign_in_at, ip и т. Д.) Для потомков
3. В рамках этого сохранения Audited затем пытается создать аудит для этого изменения.
4. Audited пытается установить пользователя для этого аудита, чтобы указать, кто внес изменение.Как оно это делает?
5. Проверенные вызовы current_user, метод Devise.Разработка еще не завершена с его методом аутентификации, начиная с шага 1 - Audited вмешался и делает свое дело.Итак,
6. Метод current_user повторяет шаг № 1 (метод authenticate_user!), Создавая бесконечный цикл
7. Ошибки вашего приложения при слишком высоком уровне стека

@Обходной путь DGM просто говорит Audited не проверять это изменение, что может сработать для вас.Тем не менее, в моем приложении мне нужно проверить это изменение.

Audited позволяет вам указать другой метод для использования current_user.

В контроллере приложения добавьте новый метод, ссылаясь на переменную экземпляра current_user .

def my_cool_method
    @current_user
end

И затем в config / initializers / audited.rb укажите Audited для использования вашего нового метода:

Audited.current_user_method = :my_cool_method

С этим изменением Audited все равно будет проверять изменения, ноон не будет пытаться установить пользователя аудита (человека, который внес изменение) - это будет ноль.

Еще одно преимущество этого изменения по сравнению с альтернативным решением DGM состоит в том, что мы не переопределяем метод Devise current_user, что похоже на исправление обезьян в том, что оно может привести к непредвиденным последствиям позже.

Answer 2

Дальнейшее объяснение - acts_as_audited вызывает current_user перед проверкой того, что игнорировать, и если current_user инициирует изменение таблицы, снова вызывает аудит, poof.Бесконечный цикл.

Мой обходной путь с той же проблемой с authlogic - отключить аудит при настройке сеанса:

def current_user
  return @current_user if defined?(@current_user)
  User.without_auditing do
    @current_user = current_user_session && current_user_session.user
  end
  @current_user
end

Однако я все еще сталкиваюсь с некоторыми другими обратными вызовами, которые я бы предпочел не делатьудар.Это проблема authlogic, а не act_as_audited.

В конечном счете, я бы предпочел, чтобы аудит, выполняемый devise или authlogic, выполнялся таким образом, чтобы обойти проверки, обратные вызовы и временные метки.

Answer 3

Просто чтобы закрыть это.

слишком большой уровень стека вызван тем, что в devise встроен аудит для переменной current_user.

Таким образом, каждый раз, когда вы обращаетесь к переменной, она вызывает бесконечный цикл.

Answer 4

То же самое происходит с одним Authlogic.Решение состоит в том, чтобы добавить аргумент: кроме следующих полей (см. Ниже).Возможно, что-то подобное будет работать и с Devise.

# В противном случае явно определите «Уровень стека слишком глубокий»

acts_as_audited: исключением => [: persistence_token,
: perishable_token,: login_count,
: failed_login_count,
: last_request_at,: current_login_at,: last_login_at,: current_login_ip,
: last_login_ip]