extracting status does fail with devise when authentication fails

[tisba]

(I'm using rails 4.0.3, devise 3.2.3 and lograge 0.3.0.)

I'm not sure if this is really devise devise specific. When I make a request that fails authentication it returns a 401 Unauthorized. lograge does log this with status=0 though. When I look at payload in https://github.com/roidrage/lograge/blob/master/lib/lograge/log_subscriber.rb#L56-L65, I get

{:controller=>"TestsController", :action=>"index", :params=>{"action"=>"index", "controller"=>"tests"}, :format=>"*/*", :method=>"GET", :path=>"/tests"}

which is obviously the reason why status=0 gets logged.

With lograge disabled I get this log entry by rails:

Started GET "/tests" for 127.0.0.1 at 2014-03-14 10:45:49 +0100
Processing by TestsController#index as */*
Completed 401 Unauthorized in 8ms

I'm wondering if I am overlooking something here and if this can be somehow fixed. Anyone else seeing this issue?

[marshally]

I'm also seeing this issue on device sign_in/sign_out endpoints.

[kuinak]

I ran into this issue too and dug a bit deeper. It happens because devise sets the status here:

https://github.com/plataformatec/devise/blob/master/lib/devise/controllers/helpers.rb#L77

which is usually called by rails here:

https://github.com/rails/rails/blob/master/actionpack/lib/action_controller/log_subscriber.rb#L21

However, lograge uses its own LogSubscriber to process the notifications from rails:

https://github.com/roidrage/lograge/blob/master/lib/lograge/log_subscriber.rb#L8

The easy fix would be to call ActionController::Base.log_process_action(payload) from the lograge code, however, this doesn't seem right to me.

[rylwin]

I ran into this same problem in our production app today and in order to help confirm the source I made a small rails app. I should have looked here first as it seems the culprit has already been identified! In case it's helpful I'll still drop the link here: https://github.com/rylwin/lograge-devise-test.

[wagner]

I've managed to log a 401 overriding Devise::SessionsController#new and responding with a status: :unauthorized. Not proud tho.

[milgner]

Just encountered this problem, too. Since the issue was closed a few days ago, does this mean that it has been fixed in upstream?

[benlovell]

Sadly not it seems. I'll reopen this and take a look today.

[mikaelhm]

Just encountered this too.
Why is @kuinak's suggestion problematic?

The easy fix would be to call ActionController::Base.log_process_action(payload) from the lograge code

[bradseefeld]

We have been having this issue as well.

http://stackoverflow.com/questions/42142503/rails-server-returning-http-status-0

In our case, its because CSRF fails. However, we do use devise, but from a few requests I have sampled, its not caused by a devise 401. In all our cases, its because of the protect_from_forgery issuing a redirect to our sign in page.

[brucew]

I am having this issue since switching to Lograge 3 months ago and like @bradseefeld it doesn't appear to be just Devise 401s. Using Lograge 0.4.1 with Rails 4.2.8 and Devise 4.2.1. I'm surprised this has been an issue since March 2014.

[benlovell]

The devise issue is caused by the problem described here: heartcombo/devise#4375.

Despite the apparent failure by lograge to accommodate this I'm reluctant to handle the special case caused by devise.

@brucew If you're experiencing issues outside of devise - post a reproduction for me to investigate.