2011-04-29 14 views
49

Todas las preguntas que he encontrado están relacionados de una conexión exitosa con el ayudante after_sign_in_path_for(resource)Diseñar redirigir después de inicio de sesión fallan

Tengo un formulario de inicio de sesión en el índice del sitio, y cuando el inicio de sesión no se vuelven a dirigir a "users/sign_in"

¿Pero cómo puedo redireccionar a mi "índice de índice de sitio" cuando falla el inicio de sesión?

+6

¿Esto funcionó para usted? Por favor márcalo si es así. –

Respuesta

1

Puede cambiar la ruta predeterminada de inicio de sesión.

Salida https://github.com/plataformatec/devise/wiki/How-To:-Change-the-default-sign_in-and-sign_out-routes

+0

Gracias @MikeH, probé esto. ** devise_for: los usuarios hacen consiguen 'usuarios',: a => 'índice de sitio #',: AS =>: user_root # 3 rieles final ** Works redireccionamiento perfecto para mi índice para todos los casos, excepto cuando falla un inicio de sesión. En este caso, se redirecciona al usuario/sign_in, y quiero que se me redireccione a "site # index". – Juanjo

+0

Hmm. Cuando falla el inicio de sesión, la aplicación de falla del desarrollador redirige a ** nuevo _ # {alcance} _session_path ** (new_user_session_path en su caso). Cuando realiza ** rutas de rastreos **, ¿qué controlador/acción se muestra para esta ruta de recursos? – MikeH

+4

¿Encontró una respuesta? Todavía lo estoy buscando ... – ronnieonrails

87
  1. Crear una custom_failure.rb en el directorio lib, con:

    class CustomFailure < Devise::FailureApp 
        def redirect_url 
        your_path 
        end 
    
        def respond 
        if http_auth? 
         http_auth 
        else 
         redirect 
        end 
        end 
    end 
    
  2. En inicializador a diseñar, incluye:

    config.warden do |manager| 
        manager.failure_app = CustomFailure 
        end 
    
  3. Hacer Asegúrese de que Rails esté cargando sus archivos lib, en su aplicación.rb :

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

No se olvide de reiniciar el servidor.

No creo que haya una manera más fácil de hacer esto. Buena suerte.

+2

Esto no funcionó. Sé que es la respuesta original de la wiki del inventor. – dsaronin

+0

¡increíble! funciona para mí :) – abhijeetmisra

+0

¡También funciona para mí, genial! –

12

Si utiliza su propia SessionsController, puede volver a asignar el valor de :recallauth_options recordar la controller#method desea antes de ejecutar warden.authenticate!(auth_options), por ejemplo:

en app/controllers/usuarios/sessions_controller.rb

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

De esta manera, no necesita crear la FailureApp personalizada y modificar las configuraciones.

+1

Esto modifica la URL para que sean los usuarios/sign_in – Edward

+0

Este es un mejor enfoque. –

3

Esto es lo que sucede con el legado 3.1.0

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

nuevo se vuelve a llamar a causa de las auth_options definidos al final de gemas/idear-3.1.0/app/controllers/diseñar/sessions_controller.rb

Debe volver a definir las auth_options utilizadas en la acción de creación. He copiado el controlador en app/controllers/diseñar/sessions_controller.rb de mi aplicación Rails y sustituye el método auth_options como esto

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

Se hace el truco, pero la URL es todavía/usuarios/sign_in

Trataré de arreglar eso también.

+0

Estoy en el diseño 3.2.2 ahora. La solución de Marcao funciona a la perfección. No es necesario copiar y parchear diseñar controladores o configurar auth_options. – pmontrasio

0

Elaborando la respuesta de Marcao, le recomiendo que coloque algunos debugger en su método CustomFailure responder para comprender mejor lo que está sucediendo.

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

Si nos fijamos en la FailureApp Devise Source Code para el método responden es muy fácil de entender lo que está pasando.

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

Así, por ejemplo, con el fin de devolver un REDIRECT_URL que usted quiere asegurarse de que sus respond condicionales código de tiempo volverá redirect.

Sin embargo, si desea devolver un estado 401 estándar como se define en el método http_auth, quiere verificar que su código de método respond devuelva .

Por lo tanto, vale la pena su tiempo para mirar en la definición de la http_auth? En particular, tenga en cuenta el: Método request.xhr?, que devolverá 0 para peticiones JSON (recuérdese que 0 evalúa en realidad para cierto en rubíes)

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

Y tal vez verifique su archivo de inicializadores/inventarios para config.http_authenticatable_on_xhr o config.navigational_formats para controlar la respuesta que desea. Esta configuración realmente puede afectar lo que devuelve Devise y, a menudo, puede conducir a un comportamiento inesperado debido a lo que hace aquí bajo el capó.

Cuestiones relacionadas