#ruby-on-rails #ruby #authentication #devise #ruby-on-rails-6
#ruby-on-rails #ruby #аутентификация #разработка #ruby-on-rails-6
Вопрос:
Я переношу это из-за проблемы в репозитории разработки, поскольку я еще не знаю, действительно ли это ошибка. Я надеюсь, что кто-нибудь может помочь мне понять, почему мои сеансы разработки истекают так быстро.
Окружающая среда
Ruby 2.7.2 Rails 6.1 Разработка 4.7.3
Текущее поведение
Моя цель состояла в том, чтобы сохранять сеансы около 30 дней, прежде чем требовать от пользователя повторного входа в систему. С помощью стандартного devise, no invitable, я видел правильно сохраненное время сеанса в моих настольных браузерах, но короткие сеансы (истекающие в днях, иногда в часах) на мобильных устройствах. Я понял, что, возможно, мне нужно использовать :timeoutable
Я установил :timeoutable для пользовательской модели, включил и установил config.timeout_in в 29.days в devise.rb. За исключением того, что теперь с :timeoutable настроенными вместо более длительных сеансов 29.day все сеансы браузера закрываются примерно через час или два.
Ожидаемое поведение
Сеанс должен сохраняться в течение 29.дней, прежде чем требовать от пользователя повторного входа в систему.
Я чувствую, что мне не хватает чего-то очевидного, но я не могу его найти. Разве :timeoutable это не правильный способ добиться этого?
Обновить:
Эта проблема разрешилась сама собой после перемещения моего приложения из поддомена в корневой домен. На самом деле это не ответ, но я хотел добавить его сюда для контекста. Помимо этого, я думаю, что следующим лучшим ответом было бы настроить собственное хранилище файлов cookie rails.
Несмотря на это, я все еще не убежден, что timeoutable работает правильно.
Ответ №1:
Сеансы совершенно сбивают с толку, потому что мы используем один и тот же термин для очень многих разных вещей.
Первый — это механизм низкого уровня ActionDispatch::Session , предоставляемый Rails. Это состоит из набора промежуточного программного обеспечения, которое связывает идентификатор сеанса (который идентифицирует клиента, подключенного к приложению по запросам) с хранилищем сеансов. Это действительно может сохранять любой простой сериализуемый объект в запросах, и, хотя он чаще всего используется для аутентификации, он также выполняет другие действия, такие как флэш-сообщения.
Хранилище сеансов по умолчанию ActionDispatch::Session::CookieStore , безусловно, самое быстрое, но есть также несколько вариантов хранения данных сеанса на сервере. Вы устанавливаете время истечения срока действия файлов cookie для хранения сеанса через:
Rails.application.config.session_store :cookie_store, expire_after: 30.days
Тогда есть то, что вы могли бы назвать сеансами аутентификации, которые на самом деле просто сохраняют утверждение (идентификатор) в тайнике, чтобы пользователю не нужно было предоставлять учетные данные (адрес электронной почты, пароль) в каждом запросе. В Devise все это обрабатывается драгоценным камнем Warden. При входе в систему Warden помещает этот идентификатор пользователя в хранилище сеансов и удаляет его при выходе из системы. Это регистрирует вас при входе / выходе при использовании определенного клиента. По умолчанию здесь нет фактического тайм-аута — он длится столько, сколько cookie-файл хранилища сеанса.
Именно здесь появляется модуль Timeoutable. Он сохраняет дополнительную временную метку вместе с идентификатором, и если срок действия временной метки истек, Warden отклонит идентификатор пользователя, сохраненный в сеансе, и удалит его. Обратите внимание, что если cookie-файл действительно истек до этого, весь процесс является спорным.
Комментарии:
1. Это информативно, и я еще не устал расширять rails
session_store, но мог бы. Я не понимал, что это за Надзиратель и:timeoutableявляется «правильным» методом. Я все еще не понимаю, почему конфигурация не работает на мобильных устройствах. Мне остается только предположить, что это конфликт с тем, как быстро истекли сеансы safari в iOS, но это сделало бы это ошибкой, а не проблемой конфигурации.2. В Safari есть некоторые функции защиты от отслеживания, такие как ITP, которые могут привести к быстрому истечению срока действия файлов cookie — я не совсем уверен, в чем именно проблема.
Ответ №2:
Вы можете просто добавить его в свою пользовательскую модель:
devise :timeoutable, timeout_in: 29.days
timeout_in определяет время, в течение которого пользователь может быть неактивным для повторного запроса учетных данных. То есть срок действия сеанса пользователя истекает, только если он не взаимодействует со своим приложением в течение 29 дней.
Помните, что для использования :timeoutable дополнительные столбцы не нужны, и это не работает remember_me .
Подробнее: время ожидания
Комментарии:
1. Спасибо за попытку помочь, но, когда я читаю это, я не вижу, добавляет ли какая-либо деталь сверх того, что я уже изложил, за исключением перемещения туда, где
timeout_inопределен период. Я сомневаюсь, что изменение этого определения изменит поведение.2. Я провел несколько тестов, и, по-видимому
timeout_in, определенный в devise.rb работает не так хорошо, как определено в вашей собственной модели, как я показал на примере.3. Я могу подтвердить, что это не имеет никакого значения, и сеанс все равно истек через 4 часа, а не через указанные 29.дней.