"Данные" в сеансе Rails выглядят следующим образом:
{"warden.user.user.key" => [[1], "long-random-string"]}
1 - это идентификатор пользователя. Что такое длинная случайная строка?
Это что-то обрабатывается/используется Rails или Devise?
"Данные" в сеансе Rails выглядят следующим образом:
{"warden.user.user.key" => [[1], "long-random-string"]}
1 - это идентификатор пользователя. Что такое длинная случайная строка?
Это что-то обрабатывается/используется Rails или Devise?
При входе в систему user (название модели разработки user) создается ключ "warden.user.model_name.key", который в вашем случае равен "warden.user.user.key".
Например:
{ warden.user.user.key => [[1], "$2a$10$KItas1NKsvunK0O5w9ioWu"] }
где
1 является id зарегистрированного пользователя.
$2a$10$KItas1NKsvunK0O5w9ioWu aka long-random-string является с частичным зашифрованным паролем пользователя с идентификатором 1.
Вы можете проверить это, выбрав rails console и выполнив
User.find(1).encrypted_password
## => "$2a$10$KItas1NKsvunK0O5w9ioWuWp4wbZ4iympYMqVCRmmvTGapktKqdMe"
UPDATE
Не могли бы вы рассказать мне немного об этом частичном зашифрованном пароле? почему он является частичным и не полным?
Чтобы ответить на ваш вышеуказанный вопрос в комментарии, Devise хранит частичный encrypted_password в сеансе, вызывая метод authenticatable_salt. Devise хранит частичный encrypted_password, поскольку он более надежен, чем подвергает полному encrypted_password в сеансе (хотя он и зашифрован). Поэтому первые 30 символов [0,29] из encrypted_password извлекаются и сохраняются в сеансе.
# A reliable way to expose the salt regardless of the implementation.
def authenticatable_salt
encrypted_password[0,29] if encrypted_password
end
Здесь вы можете увидеть код authenticatable_salt.
где/когда он используется? используется ли Devise или Rails или оба?
Используется Devise для проверки подлинности, чтобы проверить, зарегистрирован ли конкретный пользователь. Идеальный вариант использования - это то, как определенное приложение Rails отслеживает, как пользователь вошел в систему, когда новая страница запрашивается. Поскольку HTTP-запросы являются безстоящими, невозможно было бы сказать, что данный запрос действительно пришел от того конкретного пользователя, который вошел в систему? Вот почему сессии важны, так как они позволят приложению отслеживать зарегистрированный пользователь с одного запроса на другой до истечения срока действия сеанса.