Repository navigation
ms3_customer_token_ttl: в поставке 86400, в фоллбэках кода 604800 — срок токена зависит от наличия настройки #848
Description
Проблема
Время жизни токена покупателя задано в поставке двумя разными числами, и какое из них подействует — зависит от того, существует ли системная настройка.
Транспортный пакет создаёт настройку со значением 86400 (24 часа):
// _build/elements/settings.php:437-441
'ms3_customer_token_ttl' => [
'value' => 86400, // 24 часа
'xtype' => 'numberfield',
'area' => 'ms3_security',
],Код же подставляет 604800 (7 дней) — в пяти местах:
// src/Services/Customer/AuthManager.php:194
$ttl = (int)$this->modx->getOption('ms3_customer_token_ttl', null, 604800);
// src/Services/TokenService.php:106, 271, 796
$ttl = (int)$this->modx->getOption('ms3_customer_token_ttl', null, 604800);
// src/Utils/CookieHelper.php:48
$maxAge = (int)$modx->getOption('ms3_customer_token_ttl', null, 604800);И закрепляет 7 дней в документирующем комментарии:
// src/Utils/CookieHelper.php:26
* Lifetime from ms3_customer_token_ttl (default 604800 = 7 days).Чем это мешает
Комментарий в коде противоречит поставке. Разработчик, который читает CookieHelper, видит «default 7 days» и строит на этом ожидания. На установленном сайте действует 24 часа — расхождение в семь раз, причём в сторону более короткого срока, чем он рассчитывает.
То же уходит в HTTP-ответ. GET /api/v1/customer/token/get отдаёт lifetime как секунды TTL, умноженные на 1000. Клиент, написанный по комментарию из кода, будет считать токен живым неделю, тогда как сервер отзовёт его через сутки. Срок httpOnly cookie берётся оттуда же (CookieHelper:48), так что cookie и токен истекают согласованно — но не тогда, когда ожидает клиент.
Поведение меняется от наличия строки в БД. Если настройку удалить из админки или она не создалась при установке, срок молча вырастет с суток до недели. Для настройки безопасности это нежелательная разница: удаление строки должно либо ничего не менять, либо делать политику строже, а не мягче.
Что предлагаю
Свести к одному числу. Какое правильное — вопрос к замыслу: 24 часа разумны для гостевого токена корзины, 7 дней — для «запомнить меня» у авторизованного покупателя. Если нужны оба срока, это две разные настройки, а не одно значение с двумя дефолтами.
Минимальный вариант: оставить 86400 как значение поставки, заменить пять фоллбэков на 86400 и поправить комментарий в CookieHelper. Тогда удаление настройки перестанет менять поведение.
Отдельно стоит решить, нужен ли фоллбэк вообще: настройку создаёт резолвер, и при штатной установке она всегда есть. Константа класса читалась бы однозначнее, чем третий аргумент getOption(), повторённый в пяти местах.
Связанное
- #797 — рядом висит настройка-двойник
ms3_customer_api_token_ttl, которую не читает ни одна строка кода. Там зафиксировано, что у обеих настроек значение86400; расхождение с фоллбэками кода в том issue не отмечено. Чинить разумно одним заходом: оба дефекта в одной области админки и в одном разделе настроек.
Документация
В development/web-api/auth.md (ru + en) расхождение описано предупреждением «Два разных значения TTL в поставке», а примеры ответа приведены к lifetime: 86400000. После починки предупреждение нужно убрать.
Activity
fix(customer): скрыть хеш пароля и токен в чанках кабинета (#840, #848)…
chore(release): 1.14.2-beta1 (#911)
fix(security): allowlist полей в процессорах покупателя и пользователя (