Weiterleitung nach Anmeldung fehlschlagen

1. Erstellen Sie eine benutzerdefinierte_failure.rb in Ihrem lib-Verzeichnis mit:

   class CustomFailure < Devise::FailureApp
     def redirect_url
       your_path
     end
   
     def respond
       if http_auth?
         http_auth
       else
         redirect
       end
     end
   end
   

2. Enthalten Sie in Ihrem Devise-Initialisierer Folgendes:

     config.warden do |manager|
       manager.failure_app = CustomFailure
     end
   

3. Stellen Sie sicher, dass Rails Ihre lib-Dateien in Ihre application.rb lädt:

   config.autoload_paths += %W(#{config.root}/lib)
   

Vergessen Sie nicht, Ihren Server neu zu starten.

Ich glaube nicht, dass es einen einfacheren Weg gibt, dies zu tun. Viel Glück.

Wenn Sie SessionsController verwenden, können Sie den :recall-Wert von auth_options erneut zuweisen, um den gewünschten controller#method abzurufen, bevor Sie warden.authenticate!(auth_options) ausführen.

in app/controller/users/sessions_controller.rb

class Users::SessionsController < Devise::SessionsController
  #...
  def create
    #...
    auth_options = { :recall => 'site#index', :scope => :user }
    resource = warden.authenticate!(auth_options)
    #...
  end
  #...
end

Auf diese Weise müssen Sie die angepasste FailureApp nicht erstellen und die Konfigurationen ändern.

Dies geschieht mit devise 3.1.0

Started POST "/users/sign_in"
Processing by Devise::SessionsController#create
Completed 401 Unauthorized
Processing by Devise::SessionsController#new

new wird wegen der am Ende von gems/devise-3.1.0/app/controller/devise/sessions_controller.rb definierten auth_options aufgerufen

Sie sollten die in der Erstellungsaktion verwendeten auth_options neu definieren. Ich habe den Controller in app/controller/devise/sessions_controller.rb meiner Rails-Anwendung kopiert und die auth_options-Methode auf diese Weise ersetzt

def auth_options
  { :scope => resource_name, :recall => "Home#new" }
end

Es macht den Trick, aber die URL ist immer noch/users/sign_in

Ich werde versuchen, das auch zu beheben.

Sie können den standardmäßigen sign_in-Pfad ändern. 

Check out https://github.com/plataformatec/devise/wiki/How-To:-Change-the-default-sign_in-und-sign_out-routes

Um auf die Antwort von Marcao einzugehen, empfehle ich dringend, einen debugger in Ihre Antwortmethode von CustomFailure zu setzen, um besser zu verstehen, was los ist.

Class CustomFailure < Devise::FailureApp
  def respond
    binding.pry
    super
  end
end

Wenn Sie sich den FailureApp Devise Source Code für die Antwortmethode anschauen, ist es sehr einfach zu verstehen, was los ist.

def respond
  if http_auth?
    http_auth
  elsif warden_options[:recall]
    recall
  else
    redirect
  end
end

Um beispielsweise eine Weiterleitungsurkunde zurückgeben zu können, möchten Sie sicherstellen, dass Ihre respond-Codebedingungen schließlich redirect zurückgeben.

Wenn Sie jedoch möglicherweise einen Standardstatus 401 zurückgeben möchten, wie in der http_auth -Methode definiert, möchten Sie überprüfen, ob Ihr respond-Methodencode http_auth zurückgibt.

Daher lohnt es sich, die Definition der http_auth?.__ zu untersuchen. Beachten Sie insbesondere die: request.xhr?-Methode, die 0 für json-Anforderungen zurückgibt (erinnern Sie daran, dass 0 in Ruby tatsächlich als true ausgewertet wird)

def http_auth?
  if request.xhr?
    Devise.http_authenticatable_on_xhr
  else
    !(request_format && is_navigational_format?)
  end
end

Und vielleicht überprüfen Sie Ihre Initialisierer/Devise-Datei auf config.http_authenticatable_on_xhr oder config.navigational_formats, um die gewünschte Antwort zu steuern. Diese Konfiguration kann die Auswirkung von Devise wirklich beeinflussen und kann aufgrund dessen, was hier unter der Haube geschieht, oft zu unerwartetem Verhalten führen.