CODEWITHSUNDEEP
ruby-on-railsrubydeviseruby-on-rails-5rails-upgrade
Nathan Thomas
Nathan Thomas

Reputation: 1

Rails 5 (from Rails 4.2) and Devise 4 (from Devise 3) Upgrade: Warden::Proxy Instance Not Found in Request Environment

So we’re in the process of upgrading an old Rails 4 app. We’re currently trying to jump from Rails 4.2 to 5.0. Part of this involves upgrading Devise from version 3 to version 4. We’ve been jumping late in version 4 because this should be compatible with Rails 5, at least according to docs and railsbump.org

So far, the bundle install is succeeding and the server starts up, but visiting any page results in some errors from devise that we’ve had trouble figuring out:

Error during failsafe response: Devise could not find the `Warden::Proxy` instance on your request environment.
Make sure that your application is loading Devise and Warden as expected and that the `Warden::Manager` middleware is present in your middleware stack.
If you are seeing this on one of your tests, ensure that your tests are either executing the Rails middleware stack or that your tests are using the `Devise::Test::ControllerHelpers` module to inject the `request.env['warden']` object for you.
  /home/josh/.rbenv/versions/2.7.6/lib/ruby/gems/2.7.0/gems/devise-4.9.2/lib/devise/controllers/helpers.rb:143:in `warden'
  /home/josh/.rbenv/versions/2.7.6/lib/ruby/gems/2.7.0/gems/devise-4.9.2/lib/devise/controllers/helpers.rb:126:in `current_user'
  /home/josh/.rbenv/versions/2.7.6/lib/ruby/gems/2.7.0/gems/paper_trail-4.0.2/lib/paper_trail/frameworks/rails/controller.rb:19:in `user_for_paper_trail'
  /home/josh/.rbenv/versions/2.7.6/lib/ruby/gems/2.7.0/gems/paper_trail-4.0.2/lib/paper_trail/frameworks/rails/controller.rb:65:in `set_paper_trail_whodunnit'

From the stack trace, we can see that current_user is being called from some paper_trail code that we don’t control. We can override the offending paper_trail user method in ApplicationController and control what happens there. This allows us to control all instances of current_user and user_signed_in? . If we comment all of this out such that these methods aren’t used, there are no errors and pages will load. At the very least, this can allow us to make progress on some other things, but obviously we need these helpers to work if the app is going to function properly.

The error message mentions testing and lots of research around this problem via google, ChatGPT, etc also calls out testing. But this is not happening in the testing environment, and we’re confident this isn’t the issue.

The Warden::Manager middleware is also present in the middleware stack for the app.

This Issue brought up some interesting ideas. Our app is using a custom exceptions app, but unlike the user who brought up that issue, this app does not inherit from ApplicationController. Commenting out this code doesn’t get rid of the problem. Here’s the code for the custom exceptions though, just in case someone notices something with it:

  def call(env)
    status = env["PATH_INFO"][1..-1]

    if status == "404" || status == '422' || status == '500'
      Rails.application.routes.call(env)
    else
      super
    end
  end
end```

Upvotes: 0

Views: 146

Answers (1)

Nathan Thomas
Nathan Thomas

Reputation: 1

We figured out the issue. It turns out, the web-console middleware had an error in it and we just needed to bump web-console's version forward some. The error message was super confusing because of the order certain things occur in the middleware between logging, web-console, and devise/warden

Upvotes: 0

Related Questions