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

[Ивано++]

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

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

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?

[Dmitry Dulepov]

RealURL и core тут не при чем. Если вам передали неправильный uid, вы вызываете $GLOBALS['TSFE']->paheNotFoundHandler('Иди на фиг, хакер поганый!') в своем расширении и все. Никаких проблем.

[Ивано++]

Вначале думалось проверять useCashHash - в таблицах realurl. Но после нашел - как проверить useCashHash (вернее typolink-ссылки с useCashHash=1) - оказывается через калькуляцию ссылки. Для 404-обычно использую - $GLOBALS['TSFE']->pageNotFoundAndExit();