Защита скрипта, предназначенного для крона, от случайного запуска из вне
Всем привет!
Вот есть скрипт, который лежит в корне сайта, и который предназначен для запуска через крон. Как предотвратить его выполнение при запуске из браузера?
P.S. Предположим, что кто угодно может обратиться к этому файлу, набрав его в адресной строке и кто угодно знает адрес.
И желательно разрешить выполнять его залогиненному админу.
Я накидал вот такое решение:
Достаточно ли этого? Или есть ещё какие-нибудь нюансы?
Спасибо!
Вот есть скрипт, который лежит в корне сайта, и который предназначен для запуска через крон. Как предотвратить его выполнение при запуске из браузера?
P.S. Предположим, что кто угодно может обратиться к этому файлу, набрав его в адресной строке и кто угодно знает адрес.
И желательно разрешить выполнять его залогиненному админу.
Я накидал вот такое решение:
<?php
error_reporting(E_ALL);
ini_set("display_errors", 1);
define('MODX_API_MODE', true);
require 'index.php';
$modx->getService('error','error.modError');
$modx->setLogLevel(modX::LOG_LEVEL_INFO);
$modx->setLogTarget(XPDO_CLI_MODE ? 'ECHO' : 'HTML');
$userId = $modx->user->id;
if ($userId != 1 && !XPDO_CLI_MODE) {
header('HTTP/1.1 404 Not Found');
exit;
}
if (!XPDO_CLI_MODE) set_time_limit(0);Достаточно ли этого? Или есть ещё какие-нибудь нюансы?
Спасибо!
Комментарии: 18
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Представьте ситуацию, что есть некий сайт, который предоставляет некое апи для доступа к своим данным, которые периодически обновляются. Заранее об обновлениях неизвестно, да и обновления не такие уж и частые.
Поэтому пишем скрипт для работы с этим апи, чтобы проверять обновления данных и отображать их у себя, ставим в крон, к примеру раз в сутки в ночное время, когда нагрузка на сервер небольшая. А может быть и раз в двое суток — обновления-то не частые.
Но вот я заметил, что произошло обновление этих данных на том самом сайте и мне не за чем ждать до ночи, чтобы эти обновления увидеть у себя. А то и до ночи следующего дня.
Тогда я просто логинюсь в админку, открываю в браузере свой файл и, собственно, вуаля :-)
Поэтому отсекаем всех, кто не из консоли и кто запускает скрипт через веб-сервер, кроме авторизованного юзера с id администратора. который залогинен:
Просто может есть ещё какие-то тонкости, о которых я не подумал?
Если вы можете через консоль сами обновить данные, и крон это делает сам, то закройте файл вообще для внешнего мира через конфиг nginx или apache.
Нужно — зашли на сервер по ssh, запустили свой скрипт и все.
Ну это уже больше прихоти, конечно :-) Да к тому же, не сильно влияющие на конечную безопасность.
Да и не такой уж и большой огород :-)
Но планирую слезать с апача. А nginx пока не знаю. С ним ещё только буду разбираться.
Поэтому такой вариант не особо рассматриваю. Но спасибо, что напомнили :-)
Просто времени с этим разбираться пока нету, а переезд будет не завтра и не послезавтра. Поэтому изучение nginx'а пока откладываю.
А вот решение с кроном уже сейчас нужно.
а запускать так:
site.ru/cron.php?key=DY3lcju42hwC
Такой адрес запишется во все логи по всей цепочке «пользователь» => «сервер».
В том числе всякими Яндекс.Недобраузерами и иже с ними, роботы которых любят посещать проснифанные урлы на предмет индексации.
Так что это вообще не выход)