Что происходит в ядре, когда идет запрос битых адресов...

[Ивано++]

Добрый вечер...

Вопрос про разработку расширений и ссылки к ним...
Допустим у нас есть некое расширение, которое создает ссылки:
С самым простым примером постраничный листер

tx_myext_pi1[page] = 5 или даже index.php?id=342343 (где id= значению не существующей страницы).

И здесь получается, что параметр 5 - может быть любым - пользователь взял и от бума ввел 8484 - естественно такой страницы не существует...

Как себя в таком случае ведет именно ядро системы...
Ведь по идее мы не должны к данному _GET-запросу создавать кэш страницы...

Как этот вопрос решается.
Т.е. вопрос о битых URL-значениях?

И если ситуация такая - что допустим мы отправили - 404-ошибку...
Т.е. получается что у нас при каждом запросе не существующей страницы каждый раз создается уникальная 404-страница - которая по идее еще и кэш будет создавать при каждом новом не верном значении № страниы....

Или так понимаю, что к каждой подобной ссылке:
tx_myext_pi1[page] = 5 - я добавляю "useCacheHash" - и нет проблем?


Просто не совсем пойму, даже если я добавил этот useCacheHash = true
и пользвователь запросил не существующую страницу
tx_myext_pi1[page] = 5432... то получается по данному битому адресу у нас все равно будет сгенерированна новая страница - но без записи кэша в БД - правильно ли понимаю?

и useCacheHash = true к каждой подобной ссылке - решит все проблемы и мое беспокойство по этому вопросу напрасно...
Просто - что если какой нибудь, назовем его нехорошим человеком, решит запарсить (загрузить что бы повесить) мой сайт битыми ссылками... Ведь движок же каждую из них будет обрабатывать... И мне главное что бы ничего лишнего не писалось ко мне... И что бы в случае таких атак сайт не провис...

Вот пример битой ссылки:
http://typo3.org/fewfewfewfwefew/fwefewfewfwefwe

Это я сделал 1 - запрос по данному адресу...
А с помощью программ я могу делать таких запросов 1000 в минуту с разными комбинациями...
И если у меня будет в БД что-то лишнее писаться, то БД многократно будет увеличиваться...
И человек поставивший цель завалить мой сайт - с ней успешно справиться.

--
Спасибо.

[Ивано++]

И вот еще вопрос то про "useCacheHash".

useCacheHash у нас получится только в том, случае если пользователь ходит по сайту...

А вот если он сделает прямое обращение к странице...
/about/page-1/ ?

к примеру - то это как будет выглядеть - где здесь useCacheHash?
хотя если бы он (пользователь) ходил по ссылкам на сайте - то у него было бы useCacheHash в ссылках.

[Ивано++]

Там и не понял как хэш к ссылкам добавляется...
Когда делается прямой заход...

[dmartynenko]

Хэш добавляется только при генерации ссылки ядром. В случае RealURL хэша не видно, но он есть. Просто сохраняется в отдельной таблице url+хэш и убирается из выводимого на страницу url.

По остальным вопросам логика такая.

Если вы запрашиваете несуществующий id страницы, то вам вернется ответ 404 и ничего ни в какие кэши не сохраниться.

Если вы запрашиваете страницу с параметром page/?tx_myext_pi1[page] = 352326 то тут происходит следующее.

1. Если нет cHash (в ссылке или кэше RealURL), то вернется из кэша содержимое страницы page/. Контент страницы будет всегда один и тот же, без учета переданных параметров. Пример - вы ссылаетесь на одну и ту же страницу с разных сайтов, баннеров с разными utm_xxx параметрами для Google Analytics.
2. Если есть cHash, то это значит что вы сгенерировали ссылку page/?tx_myext_pi1[page] = 352326 через typolink с парамером useCacheHash. Тогда при заходе по такой ссылке новое содержимое страницы (т.е. контент USER плагинов) будет записано в кэш отдельной строкой с привязкой к уникальному cHash.
3. Если у вас на странице есть плагин USER_INT, то в обоих случая вы сможете в нем обработать значение tx_myext_pi1[page] = 352326 и сделать что вам нужно - например отправить пользователя на 404 или еще куда-то.

То есть проблему "завалить сайт через кэш" создатели TYPO3 решили давно и успешно через механизм cHash. Поэтому не устаревающая классика вам в помощь: http://typo3.org/documentation/artic...ies-of-chash-1

[Ивано++]

Сообщение от dmartynenko

Хэш добавляется только при генерации ссылки ядром. В случае RealURL хэша не видно, но он есть. Просто сохраняется в отдельной таблице url+хэш и убирается из выводимого на страницу url.

По остальным вопросам логика такая.

Если вы запрашиваете несуществующий id страницы, то вам вернется ответ 404 и ничего ни в какие кэши не сохраниться.

Если вы запрашиваете страницу с параметром page/?tx_myext_pi1[page] = 352326 то тут происходит следующее.

1. Если нет cHash (в ссылке или кэше RealURL), то вернется из кэша содержимое страницы page/. Контент страницы будет всегда один и тот же, без учета переданных параметров. Пример - вы ссылаетесь на одну и ту же страницу с разных сайтов, баннеров с разными utm_xxx параметрами для Google Analytics.
2. Если есть cHash, то это значит что вы сгенерировали ссылку page/?tx_myext_pi1[page] = 352326 через typolink с парамером useCacheHash. Тогда при заходе по такой ссылке новое содержимое страницы (т.е. контент USER плагинов) будет записано в кэш отдельной строкой с привязкой к уникальному cHash.
3. Если у вас на странице есть плагин USER_INT, то в обоих случая вы сможете в нем обработать значение tx_myext_pi1[page] = 352326 и сделать что вам нужно - например отправить пользователя на 404 или еще куда-то.

То есть проблему "завалить сайт через кэш" создатели TYPO3 решили давно и успешно через механизм cHash. Поэтому не устаревающая классика вам в помощь: http://typo3.org/documentation/artic...ies-of-chash-1

В общих и конкретных чертах теперь окончательно ясно.

[Ивано++]

Но проблема пока осталась.

Мне надо как-то получить уникальное значение правильной страницы (т.е. той которая без 404-ошибок) и имеет кэш/хеш...


Два сценария:

1) обычная страница (id)
2) обычная страница (id) + наш работающий плагин - создающий ссылки с useCacheHash

Если есть правильный ключ (для сценария 1/2) - то, я выполняю определенное действие, если нет - значит не выполняю...

Просто почему я его еще (cHash) - не могу брать из URL и делать действия по нему...:
к примеру:
adressen.html?tx_ttnews[sorting]=tx_lonewsadress_zip&tx_ttnews[direction]=dec&cHash=d4c3d91f14

Так это потому, что я могу поменять сам cHash - в данном адресе...
И мне нужно как-то проверить, правильный (т.е. существующий) - ли cHash передан?

В общем - как можно проверить - создался ли кэш в сценарии 1 или в сценарии 2?

[Ивано++]

В общем суть проблемы...
Значение я сгенерировал из трех параметров:

ID.страницы | Тип страницы | и cHash

Но проблема с realurl вот в следующем:

PHP код:

$TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT'] = array (
  
        'init' => array (
      
            'enableCHashCache' => true, 


При первом заходе мы имеем cHash...
А при повторном заходе - cHash - уже прячится....
Соответственно имеем уже другое значение.

[dmartynenko]

Что-то я не пойму о чем вы толкуете - проверять cHash вручную... Зачем?
Может опишите задачу которую хотите решить более обще?

[Ивано++]

В общем тогда суть задачи опишу...

Проблема №1.
И кстати - посмотрел (попробовал) сделать битые адреса на сайте который работает на typo3.

Беру от "туды не сюды":

http://site-name/weffwefwe/fwefwe/fwefwefwe/fwefwefwe-1
http://site-name/weffwefwe/fwefwe/fwefwefwe/fwefwefwe-2
http://site-name/weffwefwe/fwefwe/fwefwefwe/fwefwefwe-3
http://site-name/weffwefwe/fwefwe/fwefwefwe/fwefwefwe-4
http://site-name/weffwefwe/fwefwe/fwefwefwe/fwefwefwe-....
http://site-name/weffwefwe/fwefwe/fw...fwefwe-1000032

И так далее - и что интересно ... вся эта лабуда будет находить свое отражение в двух таблицах (хотя адреса битые - и по ним идет 404-ошибка!:

sys_log (если конечно не отключено ведение логов в localconf - хотя у меня не получалось на 100%-их ведение отключить - отключаешь - все равно что-то пишется...
tx_realurl_chashcache (если на сайте установлено расширение realurl)

Причем не важно - правильный или бытый адресе...
Все равно в tx_realurl_chashcache - будут писаться строки:
0185ffa2f1afa6f2ef1f22d1f4826305 468f8782df5c94cb79eb2dd5642490dc


А соответственно - значит что если сделать много битых адресов - то размеры этих таблиц будут постоянно расти - и "убивать" сайт.


Суть задачи в том, что нужно как-то сохранять кэш для smarty....
Но сейчас то, как есть - получается если запросить вариант битого адреса

http://site-name/weffwefwe/fwefwe/fw...fwefwe-1000032

то кэш будет сохраняться и по нему...
а это го не нужно....

Т.е. примерно так:

PHP код:

$cache_id = $GLOBALS['TSFE']->id . "." . $GLOBALS['TSFE']->type . "." . $GLOBALS['SMARTY_COBJ_TEMPLATE_COUNTER'] . "." . $GLOBALS['TSFE']->cHash; // . "." . $parentObject -> currentRecord . "-" . $TypoScriptKey; 


Нашел как вариант - составлять список разрешенных к сохранению в кэш страниц...
А кэш будем ($cache_id) - сохранять по:

"имени сайта . запрошенного адреса . № элемента на странице..."

И при запросе страницы - второй раз - если она попала в список разрешенных будем разрешать сохранение элементов на ней в кэш... А если была 404-ошибка . то страница не попадает в список разрешенных страниц....

И тогда, что бы все верно работало - нужно что бы везде стояли 404-ошибки...
Т.к. по ним будет определяться - разрешено заносить страницу в кэш или нет (вернее объекты, которые на ней есть)...

Думаю - что вполне подойдет для проектов до 1 000 страниц.

Здесь вопрос в том, что 404- ошибку приходиться устанавливать, как для страницы (причем эти процессы автоматизированны) - а вот с плагинами - 404-ошибку приходиться устанавливать в ручную - в зависимости от логики, которая там применяться...

[Ивано++]

В общем 2-проблема в том, что у меня:

cHash - скрывается realurl...
Первый раз я получаю страницу с этим cHash...
А потом без - т.к. он прячется и не могу понять этот механизм.

Ведь URL-адрес один и тот же...
А вот внутренние переменные уже другие.