ruby-on-rails - personalizar - rails admin

¿De qué están compuestos los datos del alcaide en una sesión de Rails/Devise?

Question

Los "datos" en una sesión de Rails se ven así:

{"warden.user.user.key" => [[1], "long-random-string"]}

1 es el ID de usuario. ¿Cuál es la cadena aleatoria larga?

¿Es esto algo manejado / usado por Rails, o Devise?

Answer 1

Cuando inicia sesión en un user (nombre de modelo de user Devise), se crea una clave "warden.user.model_name.key" que en su caso es "warden.user.user.key" .

Por ejemplo:

{ warden.user.user.key => [[1], "$2a$10$KItas1NKsvunK0O5w9ioWu"] }

dónde

1 es el id del usuario que ha iniciado sesión.

$2a$10$KItas1NKsvunK0O5w9ioWu aka long-random-string es la contraseña parcial encriptada del usuario con id 1 .

Puedes verificar esto yendo a la rails console y ejecutando

User.find(1).encrypted_password  
## => "$2a$10$KItas1NKsvunK0O5w9ioWuWp4wbZ4iympYMqVCRmmvTGapktKqdMe"

ACTUALIZAR

¿Podría decirme algo más sobre esta contraseña parcial encriptada? ¿Por qué es parcial y no está lleno?

Para responder a su pregunta anterior en el comentario, Devise almacena la contraseña encrypted_password parcial en la sesión invocando el método authenticatable_salt . Devise almacena la contraseña encrypted_password parcial ya que es más confiable en lugar de exponer la contraseña cifrada completa en la sesión (aunque esté cifrada). Es por eso que los primeros 30 caracteres [0,29] de encrypted_password se extraen y almacenan en la sesión.

  # A reliable way to expose the salt regardless of the implementation.
  def authenticatable_salt
    encrypted_password[0,29] if encrypted_password
  end

Puedes ver el código para authenticatable_salt aquí.

¿Dónde / cuándo se usa? ¿Lo usa Devise, o Rails, o ambos?

Devise utiliza con fines de autenticación para verificar si un usuario en particular está conectado o no. El caso de uso ideal sería, cómo una aplicación Rails en particular realiza un seguimiento de cómo un usuario inicia sesión cuando se solicita una nueva página. Como las solicitudes HTTP son sin estado, ¿sería imposible decir que una solicitud dada realmente provino de ese usuario en particular que inició sesión? Esta es la razón por la que las sesiones son importantes ya que permitirían a la aplicación mantener un seguimiento del usuario que inició sesión de una solicitud a otra hasta que la sesión expire.