Токены и специальные слова

Как и многие веб-приложения, MODX подписывает запросы, чтобы предотвратить обработку вредоносных запросов. WordPress выполняет это через nonces, а MODX использует токены. По умолчанию это поведение происходит только внутри панели управления MODX.

Если вы работаете с пользовательскими страницами менеджера (CMPs), вы можете увидеть следующие значения, включенные в данные post под ключом с именем HTTP_MODAUTH:

$_POST['HTTP_MODAUTH'] => modx1_65f3a2b1c9d8e7.12345678

Коннектор принимает токен по трем равнозначным каналам:

• параметр POST-запроса HTTP_MODAUTH (AJAX-слой менеджера передает его через extraParams Ext JS);
• параметр GET-запроса HTTP_MODAUTH (многие ссылки на скачивание передают его в query string);
• HTTP-заголовок ModAuth (именно так менеджер передает его по умолчанию через Ext.Ajax.defaultHeaders).

Коннектор проверяет токен в modConnectorResponse::outputContent(): пустой или несовпадающий токен приводит к ответу 401. Действие Login (и Security/Login) освобождено от проверки, чтобы можно было войти без токена. Внутри процессора HTTP_MODAUTH вычищается из $scriptProperties, поэтому код процессора его никогда не видит.

Это значение связано с пользователем и его текущим контекстом - это может показаться странным, но учтите, что сеансы также связаны с “пользователем” (даже если пользователь не вошел в систему), и вы можете начать понимать, почему соответствующий код находится в классе modUser, но поведение по умолчанию здесь заключается в том, что токены и их проверка применимы только к пользователю, который вошел в систему. Сам токен создается методом modUser::generateToken() (формат: uniqid(site_id . '_' . id пользователя, true)) и сохраняется в сеансе под ключом modx.{контекст}.user.token, когда пользователь входит в контекст через modUser::addSessionContext().

Например, вот как можно протестировать форму, которая была отправлена откуда-то из менеджера.

$token = $modx->getOption('HTTP_MODAUTH', $_POST);
if ($token != $modx->user->getUserToken($modx->context->get('key'))) {
    // ERROR! Invalid request
}

На фронтенде не нужно вызывать getUserToken вручную: процессор Login уже возвращает ключ token в ответе и для менеджера, и для web-контекста, поэтому вошедший пользователь фронтенда может переиспользовать его для аутентифицированных запросов к коннектору.

В шаблонах менеджера и CMP текущий токен доступен как плейсхолдер _authToken (его устанавливает modManagerController); в JavaScript менеджера глобальная MODx.siteId содержит его, а Ext.Ajax автоматически прикрепляет его к каждому запросу к коннектору.

Различия между Nonce и токеном¶

Nonce делает форму действительной в течение определенного периода времени, скажем 30 минут, после чего она больше не может быть успешно отправлена. В идеальном мире у вас были бы “одноразовые” формы, где каждая форма была бы уникально подписана и могла быть представлена только once. Но эта модель безопасности быстро ломается в реальном мире, где вам, возможно, придется использовать кнопку “назад”, если время загрузки страницы истекает, поэтому nonce обычно настраиваются так, чтобы быть действительными в течение определенного периода времени: чем короче окно, тем более безопасным является nonce.

Токены, используемые менеджером MODX, связаны с сеансами, поэтому, пока вы вошли в систему (т.е. ваш сеанс не истек), вы можете делать с формами все, что хотите.

Например, допустим, мы загружаем форму менеджера, затем выходим, выполняем поручения и возвращаемся через 12 часов. Если форма была подписана с помощью nonce, вы можете отправить форму, но это, вероятно, не удастся, потому что nonce обычно имеют более короткие сроки службы. Если форма была подписана с помощью токена, вы можете вероятно все еще отправить ее, потому что ваш сеанс, вероятно, все еще хорош (по умолчанию MODX поставляется с session_cookie_lifetime, равным 604800 секундам, т.е. 7 дням; значение настраивается системной настройкой).