ruby-on-rails-3 - ejemplos - django

Idear: Hacer que varios controladores manejen sesiones de usuario

Question

Estoy ejecutando el dispositivo 1.3.4 con rieles 3.0.7. Tengo dos maneras en que los usuarios pueden iniciar sesión: usar la aplicación web y usar una aplicación web móvil (a través de una llamada API JSON). La primera forma se maneja perfectamente con el controlador predeterminado de sesiones de diseño. El método de autenticación de la llamada API debe estar en un controlador que amplíe mi Api::BaseController . Entonces, escribí este segundo controlador así:

class Api::UserSessionsController < Api::BaseController
  …
  def create
    user = warden.authenticate(:scope => :user)
    if user
      sign_in(:user, user)
    else
      # Do some error handling
    end
  end
end

¿Los intentos de iniciar sesión a través de este método fallan debido a valid_controller? método en Devise::Strategies::Authenticatable . Debido a que he dejado el controlador predeterminado ( devise/sessions ) como el controlador asignado para los usuarios, no permite las autenticaciones desde mi controlador personalizado.

Me gustaría transferir mi funcionalidad personalizada a mi propia subclase de Devise::SessionsController , pero necesito el controlador de sesiones API para extender API::BaseController , por lo que no puedo extender Devise::SessionsController también. No quiero ubicar los métodos de autenticación de la aplicación web de comportamiento predeterminado en el controlador API, especialmente porque esto requeriría copiarlos del controlador de diseño.

¿Alguna sugerencia? ¿Hay alguna configuración que me falta que permita que varios controladores manejen sesiones? el valid_controller? método hace una == comparación, no .include? , así que no veo cómo funcionaría eso.

ACTUALIZAR

Esta es una terrible solución temporal. No me gusta, así que no lo estoy publicando como respuesta, pero pensé que podría ofrecer algo de reflexión para todos los tipos que respondieron:

En la parte superior de mi método de creación, podría anular lo que Devise espera sea el controlador de sesiones.

Devise.mappings[:user].controllers[:sessions] = params[:controller]

Esto funciona en función de la funcionalidad prevista de Devise (que requiere un único controlador específico para la creación de la sesión), por lo que no quiero conservarla. Me pregunto si esta restricción es una medida de seguridad o simplemente una convención; si se trata de seguridad, esto es presumiblemente bastante malo.

Answer 1

Solo puedo sugerir otra solución (¿quizás menos horrible?) En un inicializador puede sobrescribir #valid_controller ?, como este:

require ''devise/strategies/authenticatable''
require ''devise/strategies/database_authenticatable''

class Devise::Strategies::DatabaseAuthenticatable
  def valid_controller?
    # your logic here
    true
  end
end

Me interesaría saber la razón de esta restricción también

Answer 2

Estoy usando Devise 2.2.7 con Rails 3.2.13. Los dos métodos anteriores no funcionaron para mí: ¿el valid_vontroller? método en Devise::Strategies::DatabaseAuthenticatable ya no existe. El Devise.mappings[:user].controllers[:sessions] tampoco funcionó para mí.

Después de buscar este hilo encontré valid_params_request? que es responsable de garantizar que la solicitud se envíe a través del sistema de autenticación. Hay un método auxiliar, allow_params_authentication! , que es lo que permite a Devise :: SessionsController procesar las solicitudes de autenticación.

Puede autenticar a un usuario desde cualquier controlador al:

def signin
  allow_params_authentication!
  authenticate_user!
end

Si desea redirigir a una página personalizada cuando falla la autenticación:

resource = warden.authenticate!({
  :scope => :user,
  :recall => "#{controller_path}#login"
})
sign_in(:user, resource)

Me encontré con la necesidad de manejar la autenticación fuera de una subclase de Devise::SessionsController mediante el desarrollo de un motor que funciona junto con Spree Commerce, que ya implementa la autenticación de diseño.