Возможно, я устал и упускаю что-то очевидное, но я вижу странные вещи, пытающиеся отладить «Сброс токена пароля недействителен» в Rails 4.1.16, Devise 3.5.10 и Ruby 2.3.8.
Я знаю и попробовал решения здесь и здесь . Пытаясь воспроизвести шаги сброса пароля в консоли, мне интересно, есть ли более фундаментальная ошибка с моим приложением.
Я могу запустить u.send_reset_password_instructions, который успешно создает reset_password_token, фиксирует его в БД и отправляет хешированную версию в электронном письме для сброса пароля.
SQL (0.7ms) UPDATE "users" SET "reset_password_sent_at" = ?, "reset_password_token" = ?, "updated_at" = ? WHERE "users"."id" = 8 [["reset_password_sent_at", "2018-11-10 03:35:39.176325"], ["reset_password_token", "a8e9f1dd874735078fc79dbf1a72a5546edf12915eea604bc29e7da897de3c6e"], ["updated_at", "2018-11-10 03:35:39.176799"]]
Таким образом, у нас есть reset_password_token a8e9f1dd874735078fc79dbf1a72a5546edf12915eea604bc29e7da897de3c6e, который Devise хэшировал до NUY_d-cz4GsaCBJz-LPy для использования в электронной почте. Пока все хорошо.
Однако, если я запускаю User.with_reset_password_token("NUY_d-cz4GsaCBJz-LPy"), хеш корректно декодируется и БД не находит ... ничего:
User Load (3.3ms) SELECT "users".* FROM "users" WHERE "users"."reset_password_token" = 'a8e9f1dd874735078fc79dbf1a72a5546edf12915eea604bc29e7da897de3c6e' ORDER BY "users"."id" ASC LIMIT 1
=> nil
Итак, я пытаюсь вручную выполнить поиск в консоли для того же запроса: User.find_by(reset_password_token: "a8e9f1dd874735078fc79dbf1a72a5546edf12915eea604bc29e7da897de3c6e")
И я получаю ... Ничего:
User Load (4.2ms) SELECT "users".* FROM "users" WHERE "users"."reset_password_token" = 'a8e9f1dd874735078fc79dbf1a72a5546edf12915eea604bc29e7da897de3c6e' LIMIT 1
=> nil
Я уверен, что это является причиной проблем, с которыми я сталкиваюсь с 'Сброс токена пароля недействителен', но я не могу понять, почему поиск БД терпит неудачу на такой простой вещи. Есть что-то очевидное, что я должен проверять?