Idear ignorar la estrategia personalizada

Question

Esto es simplemente extraño.

Tengo Rails 3 RC ejecutándose con Devise instalado. Definí una estrategia personalizada para tratar de usar Kerberos para la autenticación.

module Devise 
    module Strategies 
    class Kerb < Devise::Strategies::Base 
     def valid? 
     params[:username] || params[:password] 
     end 

     def authenticate! 
     # cheap debugging 
     puts "PARAMS: #{params}" 

     if check_kerb_auth(params[:username], params[:password]) 
      # create user account if none exists 
      u = User.find(:first, :conditions => { :username => params[:username] }) || User.create({ :username => login }) 
      success!(u) 
     else 
      fail!("Could not log in") 
     end 
     end 

     def check_kerb_auth(username, password) 
     require 'krb5_auth' 
     include Krb5Auth 

     return false if username.blank? or password.blank? 

     begin 
      kerberos = Krb5.new 
      return kerberos.get_init_creds_password(username, password) 
     rescue Krb5Auth::Krb5::Exception 
      return false 
     end 
     end 
    end 
    end 
end 

que tienen la configuración de configuración Diseñar Warden de la siguiente manera:

config.warden do |manager| 
    manager.strategies.add(:kerb, Devise::Strategies::Kerb) 
    manager.default_strategies :kerb 
end 

consigo ningún error en mi registro. Todo parece funcionar bien. Si agrego "depuración barata" alias un montón de declaraciones de puts, parece reflejar que la estrategia de: curb es la predeterminada. Aquí es un conjunto de muestras de troncos de un intento de inicio de sesión:

=> Booting WEBrick 
=> Rails 3.0.0.rc application starting in development on http://0.0.0.0:3000 
=> Call with -d to detach 
=> Ctrl-C to shutdown server 
[2010-08-17 10:50:35] INFO WEBrick 1.3.1 
[2010-08-17 10:50:35] INFO ruby 1.8.7 (2010-01-10) [x86_64-linux] 
[2010-08-17 10:50:40] INFO WEBrick::HTTPServer#start: pid=12717 port=3000 


Started POST "https://stackoverflow.com/users/login" for 127.0.0.1 at Tue Aug 17 10:50:43 -0400 2010 
    Processing by Devise::SessionsController#create as HTML 
    Parameters: {"commit"=>"Login", "authenticity_token"=>"afZF6ho96p47dc9LQFwwNN5PqnRpl7x+1J7V3MiKgTE=", "_snowman"=>"\342\230\203", "user"=>{"remember_me"=>"1", "username"=>"hernan43", "password"=>"[FILTERED]"}} 
Completed in 0ms 
    Processing by Devise::SessionsController#new as HTML 
    Parameters: {"commit"=>"Login", "authenticity_token"=>"afZF6ho96p47dc9LQFwwNN5PqnRpl7x+1J7V3MiKgTE=", "_snowman"=>"\342\230\203", "user"=>{"remember_me"=>"1", "username"=>"hernan43", "password"=>"[FILTERED]"}} 
Rendered devise/shared/_links.erb (1.2ms) 
Rendered devise/sessions/new.html.erb within layouts/application (8.2ms) 
Completed 200 OK in 124ms (Views: 11.7ms | ActiveRecord: 1.3ms) 

El código Kerberos trabaja en otras cosas en la misma máquina. Esperaba que mostrara un montón de errores si había un problema pero no obtengo nada. ¿Hay una buena manera de depurar Devise/Warden?

Answer 1

Me he encontrado con un problema similar. Después de una breve sesión de depuración descubrí el motivo. Mi usuario no fue confirmado, por lo que después de iniciar sesión exitosamente con mi estrategia, se desconectó mediante uno de los siguientes módulos, que es el módulo confirmable :)

Btw, la forma más fácil de depurar la aplicación de rieles es usar el siguiente código :

require 'ruby-debug' 
Debugger.wait_connection = true 
Debugger.start_remote 
debugger 

y luego rdebug -c desde la terminal.

Answer 2

En caso de que alguien se encuentra con esto, aquí es lo que yo creo que el problema es:

Según Warden Strategies:

válida?

¿La válida? el método actúa como guardia de la estrategia. ¿Es opcional declarar un válido? método, y si no lo declaras, la estrategia siempre se ejecutará. Si lo declaras, la estrategia solo se probará si #valid? evalúa a verdadero.

La estrategia anterior es el razonamiento de que si hay un parámetro 'nombre de usuario' o 'contraseña', entonces el usuario está intentando iniciar sesión. Si solo hay uno de ellos, la llamada 'User.authenticate' fallará, pero sigue siendo la estrategia deseada (válida).

Así que su método válido:

def valid? 
    params[:username] || params[:password] 
end 

Está volviendo falsa, por lo que el authenticate! nunca es llamado. params es un hash anidado, por lo que debería ser params[:user][:username] en lugar de params[:username].

Cambiar su método válido para:

def valid? 
    params[:user] && (params[:user][:username] || params[:user][:password]) 
end 

volverá verdadera y causar el método authenticate! a ser llamado.