По умолчанию Devise :: SessionsController 'DELETE / users / sign_out' не выписывает пользователей

Question

У меня есть приложение с ссылкой для выхода из системы: <%= link_to('Logout', destroy_user_session_path, method: :delete) %>

После нажатия на ссылку я получаю в журналах своего сервера следующее:

Started DELETE "/users/sign_out" for 172.30.0.1 at 2019-03-06 14:52:49 +1300
Processing by Users::SessionsController#destroy as HTML
  Parameters: {"authenticity_token"=>"JLLEb2GSjGuYx+oBhsAkB0jcP0qZCJEUBvuH5VDmCS9Xbwe/hw085gumBPqJmWTtjyFeW1Io81n32NGxDuKjyQ=="}
  User Load (0.3ms)  SELECT  `users`.* FROM `users` WHERE `users`.`id` = 4 ORDER BY `users`.`id` ASC LIMIT 1
   (0.2ms)  BEGIN
   (0.4ms)  COMMIT
Redirected to https://webdev.test:3000/
Completed 302 Found in 28ms (ActiveRecord: 0.9ms) 

Затем корневая страница снова загружается, но пользователь не вышел из системы.

Я открыл вкладку в режиме инкогнито в Chrome и попытался войти в систему и выйти из нее, и она работала нормально, так что, похоже, это что-то особенное для моего браузера в обычном режиме. Я попытался перезапустить браузер, и это не имеет значения.

Учетная запись пользователя, в которую я вошел как в Devise, не увеличивает счетчик входа каждый раз, когда я это делаю, и не изменяется отметка времени updated_at.

Затем я добавил byebug в метод моего контроллера корневой страницы и запустил следующее:

   1: class HomeController < ApplicationController
   2:   def index
   3:     byebug
=> 4:     # Omitted for brevity, nothing which touches the current_user object
   5:   end
   6: end
(byebug) Devise.sign_out_all_scopes
true
(byebug) sign_out
   (0.8ms)  BEGIN
   (0.4ms)  COMMIT
true
(byebug) continue

И после этого пользователь все еще не вышел из системы.

Перезапуск приложения Rails и повторная попытка всего вышеперечисленного привели к тому же результату, я все еще не могу выйти из этого пользователя.

Кто-нибудь видел это раньше и есть идеи о том, что застревает и как я могу выйти?

Редактировать

По запросу комментатора, маршруты, относящиеся к выходу:

$ rails routes | grep sign_out
          destroy_user_session DELETE   /users/sign_out(.:format)                                   users/sessions#destroy
$ 

Вывод rails routes | grep destroy_user_session также идентичен приведенному выше, поэтому он показывает, что нет именованного маршрута, направляющего запросы к другому действию контроллера.

И контроллер на app/controllers/users/sessions_controller.rb (который переопределяет только метод create, а не метод destroy)

class Users::SessionsController < Devise::SessionsController
  def create
    # Omitted for brevity
  end
end

Answer 1

Я попробовал и создал пользовательский контроллер, чтобы проверить и, кажется, все хорошо.У меня есть только одна странная проблема, я не уверен, почему она изменилась.Речь идет о SQL Query.Ваш ответ получает следующий запрос.

SELECT  `users`.* FROM `users` WHERE `users`.`id` = 4 ORDER BY `users`.`id` ASC LIMIT 1

Почему он имеет 4 идентификатора как жестко запрограммированный, обычно это должно быть подготовленное утверждение, подобное следующему

SELECT  "users".* FROM "users" WHERE "users"."id" = ? ORDER BY "users"."id" ASC LIMIT ?  [["id", 4], ["LIMIT", 1]]

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