Можно ли ограничить количество параметров $ _GET приложением Zend Framework, использующим Zend_Cache_Backend_Static для кэширования статических страниц в виде HTML - PullRequest
3 голосов
/ 17 февраля 2012

Я только что настроил статическое кэширование страниц, используя Zend_Cache_Backend_Static для обслуживания кэшированных html-файлов в моем приложении, что прекрасно работает.Единственное, что меня беспокоит, - это способ кэширования файлов с параметрами $ _GET.Поскольку он автоматически создает структуру папок, которая сопоставляется с указанным маршрутом URL, является ли это потенциальной угрозой безопасности в случаях, когда большое количество параметров $ _GET может быть намеренно добавлено к существующим страницам?Или максимальная глубина каталога или максимальная длина файла?

Например: в данный момент я кэширую свои страницы в /public/cache/static/, поэтому использование стандартного маршрутизатора /module/controller/action/param1/val1/param2/val2 или стандартной строки запроса /module/controller/action?param1=val1&param2=val2 будетсоздать следующие структуры каталогов:

/public/cache/static/module/controller/action/param1/val1/param2/val2.html 
/public/cache/static/module/controller/action?param1=val1&param2=val2.html

Предоставление людям доступа к созданию структуры каталогов таким образом (хотя и ограниченным) меня немного беспокоит.И Zend_Cache_Backend_Static, и соответствующий Zend_Cache_Frontend_Capture должны быть установлены в INI-файле не через фабрику Zend_Cache и не должны иметь никаких параметров настройки.

Может ли это быть просто заменой маршрутизатора по умолчанию на пользовательские маршруты, которыеограничить количество переменных $ _GET?Возможно ли это, или мне нужно указать именно те переменные, которые мне нужны для каждого маршрута (не конец света, а чуть более ограничивающий)

Обновление:

Таким образом, существующее правило перезаписи для обработки статического кэша выглядит следующим образом:

RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{DOCUMENT_ROOT}/cached/index.html -f
RewriteRule ^/*$ cached/index.html [L]

RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{DOCUMENT_ROOT}/cached/%{REQUEST_URI}\.html -f
RewriteRule .* cached/%{REQUEST_URI}\.html [L]

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]

RewriteRule ^.*$ index.php [NC,L]

Если запрос попадает на страницу в статическом кэше, он отправит эту HTML-страницу.Если нет, то он ударит по Zend Framework и сгенерирует его.

Я мог бы добавить в начало следующее:

RewriteCond %{QUERY_STRING} \S
RewriteRule [^\?]+ /$0? [R=301,L]

, что полностью стерет мою строку запроса.Это нормально, так как я все еще могу передавать переменные $ _GET при использовании метода URL-пути Zend Framework (который я также ограничил, предоставляя очень явные маршруты).Но возможно ли это сделать без перенаправления?

Ответы [ 2 ]

1 голос
/ 18 февраля 2012

Идеальным способом было бы определить это как RewriteCond, но я не уверен, что с помощью mod_rewrite можно подсчитать количество параметров GET.автономный скрипт php, который решает, использовать ли кэшированные html-файлы.

<?php

if (count($_GET) >= 20) {
  require __DIR__ . 'index.php';
} else {
  require '/path/to/cache.html';
}
0 голосов
/ 20 февраля 2012

ОК, поэтому RewriteRule, удаляющий строку запроса, будет работать без перенаправления.

Проблема (я подозреваю) в том, что Zend_Cache_Backend_Static использует $ _SERVER ['REQUEST_URI'] где-то вдоль строки и поэтому получаетдоступ к оригинальному имени файла.Мои знания о mod_rewrite довольно невелики, и я не осознавал, что это значение не изменилось.

Итак, чтобы предотвратить создание файлов и каталогов с помощью массивных строк запросов, мне пришлось сделать следующие вещи:

Во-первых, для стандартных строк запроса:

Обрезать строку запроса в начале моего mod_rewrite без перенаправления:

RewriteCond %{QUERY_STRING} \S
RewriteRule [^\?]+ /$0?

В моем index.php я тогдаизменив $ _SERVER ['REQUEST_URI'] для соответствия перенаправлению, удалив строку запроса, что означает, что мне больше не нужно взламывать ZF:

$queryIndex = strpos($_SERVER['REQUEST_URI'], '?');
if($queryIndex !== false) {
    $_SERVER['REQUEST_URI'] = substr($_SERVER['REQUEST_URI'], 0, $queryIndex);
}

Это теперь предотвратит ЛЮБУЮ строку запроса отинтерпретируется моим заявлением.Поэтому для передачи переменных на страницы я использую параметры пути URL Zend Framework.Чтобы они не создавали чрезмерно глубоких папок кеша, я заменил маршрут по умолчанию на несколько очень четко определенных маршрутов в Bootstrap:

$frontController = Zend_Controller_Front::getInstance(); 
$router = $frontController->getRouter();

$route = new Zend_Controller_Router_Route(
    ':module/:controller/:action',
    array(
        'module' => 'default',
        'controller' => 'index',
        'action' => 'index'
    )
);

$router->addRoute('default', $route);

$route = new Zend_Controller_Router_Route(
    'article/:alias',
    array(
        'module' => 'default',
        'controller' => 'article',
        'action' => 'index',
        'alias' => ''
    )
);

$router->addRoute('article', $route);

Здесь я заменил маршрут по умолчанию, поэтому никаких дополнительных параметров нет.разрешены.Поэтому любые действия, которые требуют параметров, должны быть явно установлены, например, на моем втором маршруте.Это означает, что потенциально может быть много определенных маршрутов.К счастью, в моем конкретном приложении это не так.

Способ ограничения ограничений маршрутов и предоставления некоторых параметров GET через URL-пути ZF состоит в том, чтобы установить ограничение на количество слешей в REQUEST_URI, эффективно ограничиваямаксимальная глубина каталога статического кэша страниц (10 ниже).Это также может быть изменено в index.php:

if(substr_count($_SERVER['REQUEST_URI'], '/') > 10) {
    preg_match_all("/\//", $_SERVER['REQUEST_URI'] ,$capture, PREG_OFFSET_CAPTURE);
    $_SERVER['REQUEST_URI'] = substr($_SERVER['REQUEST_URI'], 0, $capture[0][9][1]);
}
...