I am running an upgraded system on ubuntu 18.04 using rails 5.2.8, ruby 2.5.1, devise 4.5.0 (problem occurs with any devise version > 4.5) and warden 1.2.9.

When I logon I get the following debug output:

[2022-06-02 13:02:21] INFO -- SIGN-IN SIGN-IN SIGN-IN SIGN-IN SIGN-IN SIGN-IN SIGN-IN SIGN-IN SIGN-IN SIGN-IN SIGN-IN SIGN-IN SIGN-IN
[2022-06-02 13:02:21] DEBUG -- Warden::Manager.after_authentication: User [email protected] has signed in.
[2022-06-02 13:02:21] INFO -- ^^^^^^^^^ check_reference: request.env['HTTP_REFERER'] = https://SERVER.com/d/users/sign_in  params[:controller] = users/sessions
[2022-06-02 13:02:21] INFO -- ======================= SessionsController: format.html  current_user: #<User signed_in: true, id: 25, email: "[email protected]", first_name: "FIRST", last_name: "LAST", role: "Administrator", auto_signout_enabled: true, password_changed: false, force_password_reset: false, updated_at: "2022-06-02 20:02:21", created_at: "2020-01-10 13:24:20">
[2022-06-02 13:02:21] INFO -- ======================== application_controller: after_sign_in_path_for
[2022-06-02 13:02:21] INFO -- Redirected to http://sbsmn/
[2022-06-02 13:02:21] INFO -- ======================= SessionsController: User [email protected] signed-in from Web browser.
[2022-06-02 13:02:21] INFO -- Completed 302 Found in 93ms (ActiveRecord: 4.0ms)
[2022-06-02 13:02:21] INFO -- Started GET "/" for 127.0.0.1 at 2022-06-02 13:02:21 -0700
[2022-06-02 13:02:21] INFO -- Processing by RuntimeController#index as HTML
[2022-06-02 13:02:21] DEBUG -- Warden::Manager.after_failed_fetch: User nil   opts: {:scope=>:user}
[2022-06-02 13:02:21] INFO -- Completed 401 Unauthorized in 1ms (ActiveRecord: 0.0ms)
[2022-06-02 13:02:21] INFO -- Warden::Manager.after_failed_fetch: User is nil? true   opts: {:scope=>:user}   auth: Warden::Proxy:20581780 @config={:default_scope=>:user, :scope_defaults=>{}, :default_strategies=>{:user=>[:database_authenticatable]}, :intercept_401=>false, :failure_app=>#<Devise::Delegator:0x0000000004d66b28>}

The debug indicates that the logon was successful (which is verified by the user table in the database). The line that reads Warden::Manager.after_failed_fetch: User is nil... is where the problem shows up. In a system where everything is working properly, the following lines should look something like

[2022-06-02 16:14:36] INFO -- ********************************* RUNTIME VIEW *********************************
[2022-06-02 16:14:36] DEBUG -- [VIEWS HELPER] get_view_connectivity view_id: 15
<<continue to load home page >>

That is, the activity immediately following a logon is a redirect to the home page. However, in this case it fails because (I think) the user (current_user?) has become nil or in some other way invalidated, so we just stay on the logon page. The nil user is detected in a warden callback as follows:

  Warden::Manager.after_failed_fetch do |user, auth, opts|
    Rails.logger.debug("Warden::Manager.after_failed_fetch: User is nil? #{user.nil?}   opts: #{opts.inspect}   auth: #{auth.inspect}".default_warn)
  end

On the system where this was working we were running rails 5.0.1, ruby 2.3.3, devise 4.2.0 and warden 1.2.7.

I also tried installing warden 1.2.7 into the 5.2.8 environment, but there was no change. The devise 4.2.0 gem requires railties (< 5.1, >= 4.1.0) so it won’t work in the new environment.

I ran into this problem before and the only solution I could find at the time was to revert back to the old versions. However, it is harder and harder to maintain systems with older versions of ruby gems. Every time a new version of a gem, or an altogether new gem is added, I might spend hours playing rubygem whack-a-mole.

This problem is also similar to:
Ruby on rails – user is nil after creating a session and redirecting home