Просмотр полной версии : Что происходит в ядре, когда идет запрос битых адресов...
Добрый вечер...
Вопрос про разработку расширений и ссылки к ним...
Допустим у нас есть некое расширение, которое создает ссылки:
С самым простым примером постраничный листер
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
10.07.2013, 18:06
Хэш добавляется только при генерации ссылки ядром. В случае RealURL хэша не видно, но он есть. Просто сохраняется в отдельной таблице url+хэш и убирается из выводимого на страницу url.
По остальным вопросам логика такая.
Если вы запрашиваете несуществующий id страницы, то вам вернется ответ 404 и ничего ни в какие кэши не сохраниться.
Если вы запрашиваете страницу с параметром page/?tx_myext_pi1[page] = 352326 то тут происходит следующее.
Если нет cHash (в ссылке или кэше RealURL), то вернется из кэша содержимое страницы page/. Контент страницы будет всегда один и тот же, без учета переданных параметров. Пример - вы ссылаетесь на одну и ту же страницу с разных сайтов, баннеров с разными utm_xxx параметрами для Google Analytics.
Если есть cHash, то это значит что вы сгенерировали ссылку page/?tx_myext_pi1[page] = 352326 через typolink с парамером useCacheHash. Тогда при заходе по такой ссылке новое содержимое страницы (т.е. контент USER плагинов) будет записано в кэш отдельной строкой с привязкой к уникальному cHash.
Если у вас на странице есть плагин USER_INT, то в обоих случая вы сможете в нем обработать значение tx_myext_pi1[page] = 352326 и сделать что вам нужно - например отправить пользователя на 404 или еще куда-то.
То есть проблему "завалить сайт через кэш" создатели TYPO3 решили давно и успешно через механизм cHash. Поэтому не устаревающая классика вам в помощь: http://typo3.org/documentation/article/the-mysteries-of-chash-1
Хэш добавляется только при генерации ссылки ядром. В случае RealURL хэша не видно, но он есть. Просто сохраняется в отдельной таблице url+хэш и убирается из выводимого на страницу url.
По остальным вопросам логика такая.
Если вы запрашиваете несуществующий id страницы, то вам вернется ответ 404 и ничего ни в какие кэши не сохраниться.
Если вы запрашиваете страницу с параметром page/?tx_myext_pi1[page] = 352326 то тут происходит следующее.
Если нет cHash (в ссылке или кэше RealURL), то вернется из кэша содержимое страницы page/. Контент страницы будет всегда один и тот же, без учета переданных параметров. Пример - вы ссылаетесь на одну и ту же страницу с разных сайтов, баннеров с разными utm_xxx параметрами для Google Analytics.
Если есть cHash, то это значит что вы сгенерировали ссылку page/?tx_myext_pi1[page] = 352326 через typolink с парамером useCacheHash. Тогда при заходе по такой ссылке новое содержимое страницы (т.е. контент USER плагинов) будет записано в кэш отдельной строкой с привязкой к уникальному cHash.
Если у вас на странице есть плагин USER_INT, то в обоих случая вы сможете в нем обработать значение tx_myext_pi1[page] = 352326 и сделать что вам нужно - например отправить пользователя на 404 или еще куда-то.
То есть проблему "завалить сайт через кэш" создатели TYPO3 решили давно и успешно через механизм cHash. Поэтому не устаревающая классика вам в помощь: http://typo3.org/documentation/article/the-mysteries-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 вот в следующем:
$TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT'] = array (
'init' => array (
'enableCHashCache' => true,
При первом заходе мы имеем cHash...
А при повторном заходе - cHash - уже прячится....
Соответственно имеем уже другое значение.
dmartynenko
11.07.2013, 13:58
Что-то я не пойму о чем вы толкуете - проверять 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/fwefwefwe/fwefwefwe-1000032
И так далее - и что интересно ... вся эта лабуда будет находить свое отражение в двух таблицах (хотя адреса битые - и по ним идет 404-ошибка!:
sys_log (если конечно не отключено ведение логов в localconf - хотя у меня не получалось на 100%-их ведение отключить - отключаешь - все равно что-то пишется...
tx_realurl_chashcache (если на сайте установлено расширение realurl)
Причем не важно - правильный или бытый адресе...
Все равно в tx_realurl_chashcache - будут писаться строки:
0185ffa2f1afa6f2ef1f22d1f4826305 468f8782df5c94cb79eb2dd5642490dc
А соответственно - значит что если сделать много битых адресов - то размеры этих таблиц будут постоянно расти - и "убивать" сайт.
Суть задачи в том, что нужно как-то сохранять кэш для smarty....
Но сейчас то, как есть - получается если запросить вариант битого адреса
http://site-name/weffwefwe/fwefwe/fwefwefwe/fwefwefwe-1000032
то кэш будет сохраняться и по нему...
а это го не нужно....
Т.е. примерно так:
$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-адрес один и тот же...
А вот внутренние переменные уже другие.
Вот еще интересная штука из API
tslib_fe :: pageNotFoundHandler("/home/", "HTTP/1.1 404 Not Found", "Segment "error-404" was not a keyword for a postVarSet as expected on page with id=2.");
dmartynenko
11.07.2013, 18:41
У вас есть какая-то принципиальная нестыковка, на мой взгляд.
cHash нужен ядру что бы *закэшировать* контент страницы и он появляется только в момент формирования typolink.
То есть ваш контент будет кэширован ядром в составе страницы с привязкой к этому самому cHash.
Зачем спрашивается внутри вашей логики что-то еще в таком случае кэшировать (и с привязкой к cHash в частности) ?
Мы используем кэширование внутри плагина только в случае USER_INT. И в данном случае cHash вообще не интересен. Используем для cache_id md5() от всего, что может повлиять на контент. Это pid, type, FE группы, ряд переменных из GET, а иногда и $this->conf целиком добавляется.
У вас есть какая-то принципиальная нестыковка, на мой взгляд.
cHash нужен ядру что бы *закэшировать* контент страницы и он появляется только в момент формирования typolink.
То есть ваш контент будет кэширован ядром в составе страницы с привязкой к этому самому cHash.
Зачем спрашивается внутри вашей логики что-то еще в таком случае кэшировать (и с привязкой к cHash в частности) ?
Мы используем кэширование внутри плагина только в случае USER_INT. И в данном случае cHash вообще не интересен. Используем для cache_id md5() от всего, что может повлиять на контент. Это pid, type, FE группы, ряд переменных из GET, а иногда и $this->conf целиком добавляется.
Да - Вы правы - ничего не пропадает...
Проблему нашел:
Есть у меня на странице LOAD_REGISTER
Суть его в том, что он выбирает ключевые слова для новости...
page.1 = LOAD_REGISTER
# Ключевые слова
page.1.new_keywords.cObject = TEXT
page.1.new_keywords.cObject.dataWrap = DB:tt_content_news:{GP:tt_content_news|view_detail _record}:seo_keywords
page.1.new_keywords.cObject.insertData = 1
page.1.new_keywords.cObject.wrap3 = {|}
На странице установлен:
$GLOBALS['TSFE']->no_cache = 1; // запрет кэширования (1)
$GLOBALS['TSFE']->set_no_cache(); // запрещяем кэширование (2)
И проблема в том - что при заходе первый раз на страницу я получаю значения из LOAD_REGISTER - все работает верно... Но вот как - только я обновляю страницу... То LOAD_REGISTER - как бы становиться пустым...
# Переопределяем заголовок
page.headerData.100.value (
<meta name="keywords" content="{register:new_keywords // DB:tx_web_settings:1:seo_meta_def_keywords}">
<meta name="description" content="{register:new_description // DB:tx_web_settings:1:seo_meta_def_description}">
<title>{register:new_title //field:subtitle // field:title} :: {DB:tx_web_settings:1:site_name}</title>
)
С удовольствием бы решил проблему следующим образом (т.к. мне не нравиться LOAD_REGISTER в принципе)...
{DB:tt_content_news:[{GP:tt_content_news|view_detail_record}]:title}
Т.е. через вставку ID-записи из _GET - но как такое сделать для DB-не нашел... В DB-можно передать просто ID-записи , а вот подставить из _GET - не нашел такого решения...
Вот полный код:
#************************************************* ******************
# Данный файл содержит описание настроек seo-материала для виртуальных страниц
#************************************************* ******************
# Определяем мета-данные для новостей (раздел 95)
[globalVar = GP:tt_content_news|view_detail_record > 0]
# Создаем новое значение
page.1 = LOAD_REGISTER
# Ключевые слова
page.1.new_keywords.cObject = TEXT
page.1.new_keywords.cObject.dataWrap = DB:tt_content_news:{GP:tt_content_news|view_detail _record}:seo_keywords
page.1.new_keywords.cObject.insertData = 1
page.1.new_keywords.cObject.wrap3 = {|}
# Описание страницы
page.1.new_description.cObject = TEXT
page.1.new_description.cObject.dataWrap = DB:tt_content_news:{GP:tt_content_news|view_detail _record}:seo_description
page.1.new_description.cObject.insertData = 1
page.1.new_description.cObject.wrap3 = {|}
# Заголовок
page.1.new_title.cObject = TEXT
page.1.new_title.cObject.dataWrap = DB:tt_content_news:{GP:tt_content_news|view_detail _record}:title
page.1.new_title.cObject.insertData = 1
page.1.new_title.cObject.wrap3 = {|}
# Переопределяем заголовок
page.headerData.100.value (
<meta name="keywords" content="{register:new_keywords // DB:tx_web_settings:1:seo_meta_def_keywords}">
<meta name="description" content="{register:new_description // DB:tx_web_settings:1:seo_meta_def_description}">
<title>{register:new_title //field:subtitle // field:title} :: {DB:tx_web_settings:1:site_name}</title>
)
[global]
# Определяем мета-данные для статей (раздел 94)
[globalVar = GP:tt_content_article|view_detail_record > 0]
# Создаем новое значение
page.1 = LOAD_REGISTER
# Ключевые слова
page.1.new_keywords.cObject = TEXT
page.1.new_keywords.cObject.dataWrap = DB:tt_content_article:{GP:tt_content_article|view_ detail_record}:seo_keywords
page.1.new_keywords.cObject.insertData = 1
page.1.new_keywords.cObject.wrap3 = {|}
# Описание страницы
page.1.new_description.cObject = TEXT
page.1.new_description.cObject.dataWrap = DB:tt_content_article:{GP:tt_content_article|view_ detail_record}:seo_description
page.1.new_description.cObject.insertData = 1
page.1.new_description.cObject.wrap3 = {|}
# Заголовок
page.1.new_title.cObject = TEXT
page.1.new_title.cObject.dataWrap = DB:tt_content_article:{GP:tt_content_article|view_ detail_record}:title
page.1.new_title.cObject.insertData = 1
page.1.new_title.cObject.wrap3 = {|}
# Переопределяем заголовок
page.headerData.100.value (
<meta name="keywords" content="{register:new_keywords // DB:tx_web_settings:1:seo_meta_def_keywords}">
<meta name="description" content="{register:new_description // DB:tx_web_settings:1:seo_meta_def_description}">
<title>{register:new_title //field:subtitle // field:title} :: {DB:tx_web_settings:1:site_name}</title>
)
[global]
# Определяем мета-данные для фотогаллереи (раздел 97)
[globalVar = GP:tt_content_gallery|directory_uid > 0]
# Создаем новое значение
page.1 = LOAD_REGISTER
# Ключевые слова
page.1.new_keywords.cObject = TEXT
page.1.new_keywords.cObject.dataWrap = DB:tt_content_gallery:{GP:tt_content_gallery|direc tory_uid}:seo_keywords
page.1.new_keywords.cObject.insertData = 1
page.1.new_keywords.cObject.wrap3 = {|}
# Описание страницы
page.1.new_description.cObject = TEXT
page.1.new_description.cObject.dataWrap = DB:tt_content_gallery:{GP:tt_content_gallery|direc tory_uid}:seo_description
page.1.new_description.cObject.insertData = 1
page.1.new_description.cObject.wrap3 = {|}
# Заголовок
page.1.new_title.cObject = TEXT
page.1.new_title.cObject.dataWrap = DB:tt_content_gallery:{GP:tt_content_gallery|direc tory_uid}:title
page.1.new_title.cObject.insertData = 1
page.1.new_title.cObject.wrap3 = {|}
# Переопределяем заголовок
page.headerData.100.value (
<meta name="keywords" content="{register:new_keywords // DB:tx_web_settings:1:seo_meta_def_keywords}">
<meta name="description" content="{register:new_description // DB:tx_web_settings:1:seo_meta_def_description}">
<title>{register:new_title //field:subtitle // field:title} :: {DB:tx_web_settings:1:site_name}</title>
)
[global]
# Значения по умолчанию (если все выше описанное оказалось пыстым)
#page.meta.keywords.ifEmpty.data = DB:tx_web_settings:1:seo_meta_def_keywords
#page.meta.description.ifEmpty.data = DB:tx_web_settings:1:seo_meta_def_description
И почему-то при обновлении станицы которая не кэшуреутся этот самый LOAD_REGISTER - становится пустым...
Извиняюсь за не точность - в данном примере ничего не пропадает...
Пропадает в навигационной цепочке - при повторном посещении некэшируемой страницы...
Где идет вставка значения через {register:new_title}
Видимо {register} - имеет область видимости переменных...
# Определяем нав.цепочку для новостей, детальный просмотр (раздел 95)
[globalVar = GP:tt_content_news|view_detail_record > 0]
lib.menuBreadcrumb.10.1.CUR >
lib.menuBreadcrumb.30 = TEXT
lib.menuBreadcrumb.30.value = {register:new_title}
lib.menuBreadcrumb.30.insertData = 1
lib.menuBreadcrumb.30.typolink {
parameter = 95
additionalParams=&tt_content_news[page]={GP:tt_content_news|page}&tt_content_news[view_detail_record]={GP:tt_content_news|view_detail_record}
additionalParams.insertData = 1
useCacheHash = 1
}
[global]
Одним словом уже запутался крепко...
Ни как не пойму - есть ли простой способ?
page.meta.keywords.data = DB:ttable:[Вставить id из _GET]:seo_meta_def_keywords
Одним словом есть ли что по проще чем:
temp.newsTitle = RECORDS
temp.newsTitle {
dontCheckPid = 1
tables = tx_news_domain_model_news
source.data = GP:tx_news_pi1|news
source.intval = 1
conf.tx_news_domain_model_news = TEXT
conf.tx_news_domain_model_news {
field = title
htmlSpecialChars = 1
}
wrap = <title>|</title>
}
page.headerData.1 >
page.headerData.1 < temp.newsTitle
Вот что получается:
Проверяю в index.php (вставляю в самый конец)...
Если на странице через php-ставить no_cahe = 1 и no_set_cache()
print "<pre>";
print_r($GLOBALS['TSFE']->register);
То при обновлении страницы часть значений из данного массива пропадает
Если поставить в настройках TS-к странице
page.config.no_cache = 1
То все значения на месте
print "<pre>";
print_r($GLOBALS['TSFE']->register);
В общемь... (нет слов)...
Разобрался...
Сделал просто LOAD_REGISTER - отдельно для breadcurmb...
Осталось несколько маленьких вопросиков:
В чем раздница между этими двумя функциями (методами)?
$GLOBALS['TSFE']->no_cache = 1; // запрет кэширования (1)
$GLOBALS['TSFE']->set_no_cache(); // запрещяем кэширование (2)
А также правильно ли понимаю, что вот у нас есть ссылка typolink c useCacheHash ... = true
lib.menuBreadcrumb.20.typolink {
parameter = 94
additionalParams=&tt_content_article[page]={GP:tt_content_article|page}
additionalParams.insertData = 1
useCacheHash = 1
}
И если мы вызываем эти два метода:
$GLOBALS['TSFE']->no_cache = 1; // запрет кэширования (1)
$GLOBALS['TSFE']->set_no_cache(); // запрещяем кэширование (2)
то useCacheHash - не генерируется?
Думаю что теперь окончательно разобрался что из чего растет.
И все равно не могу понять...
Вот есть страница:
эти у меня реально существуют
novosti/page-news/1/
novosti/page-news/2/
novosti/page-news/3/
и почему при запросе скажем
novosti/page-news/4/
- все равно генриться cHash
Я его даже получить могу для каждой страницы - новый уникальный...
$GLOBALS['TSFE']->cHash.
Эээ.... может быть чего то не понимаю...
Но вот заметил:
установил расширение realur...
вот для него есть такая настройка:
'postVarSets' => array(
'_DEFAULT' => array (
// Для раздела новостей
'page-news' => array( array ( 'GETvar' => 'tt_content_news[page]'), ),
'record-news' => array( array ( 'GETvar' => 'tt_content_news[view_detail_record]'), ),
// Для раздела статей
'page-article' => array( array ( 'GETvar' => 'tt_content_article[page]'), ),
'record-article' => array( array ( 'GETvar' => 'tt_content_article[view_detail_record]'), ),
),
),
Суть проблемы в:
Делаем запрос:
stati/record-article/14/ (запись реально есть)
stati/record-article/15/ (запись реально есть)
stati/record-article/16/ (запись реально есть)
stati/record-article/1222/ (ЗАПИСИ НЕТ... просто нет в БД)
если сделать запрос-прямой в окне браузера:
stati/record-article/1222/ - и обновить страницу...
то ,будет создан:
$GLOBALS['TSFE']->cHash - при обновлении страницы????
Ведь по идее же так не должно быть?
А $GLOBALS['TSFE']->cHash - должен создаваться только при переходе по ссылкам???
Что - то наверное я ошибся...:)
В общем последний и единственный вопрос из данной темы...
Вот если:
novosti/page-news/2/record-news/4/?cHash=5435437878787
novosti/page-news/2/record-news/4/?cHash=5435ауцацу
novosti/page-news/2/record-news/4/?cHash=5fewfwefwe
.. и так далее
А как проверить (правильно ли создан cHash) - а не через запрос от пользователя? У realurl - есть специальная таблица "tx_realurl_chashcache" - куда пишутся значения - и три выше приведенных примера cHash=5435437878787 / cHash=5435ауцацу / cHash=5fewfwefwe - он туда не пишет... А пишет только верные?...
Рассчитвыал правильные значения получать через:
$GLOBALS['TSFE']->cHash
Но проблема в том, что он выдает грубо говоря, то что приведено в ссылках выше... Т.е. не реально созданный cHash - страницы.
В общем - как проверить - useCacheHash - создан через систему - или введен "недоброжетельным" пользователем?
И никак не пойму - если realurl - не установлен - то куда тогда пишутся значения useCacheHash?
И еще нашел как-получить уникальное значение шаблона сайта (id+типа+групп+mp+иCacheHash) - массива -
возможно это поможет...
$GLOBALS['TSFE']->getHash()
Спасибо...
В общем вот нашел решение проблемы:
protected function encodeSpURL_cHashCache($newUrl, &$paramKeyValues) {
// If "cHash" is the ONLY parameter left...
// (if there are others our problem is that the cHash probably covers those
// as well and if we include the cHash anyways we might get duplicates for
// the same speaking URL in the cache table!)
if (isset($paramKeyValues['cHash'])) {
if ($this->rebuildCHash) {
$cacheHashClassExists = class_exists('t3lib_cacheHash');
$cacheHash = ($cacheHashClassExists ? t3lib_div::makeInstance('t3lib_cacheHash') : NULL);
/* @var t3lib_cacheHash $cacheHash */
$cHashParameters = array_merge($this->cHashParameters, $paramKeyValues);
unset($cHashParameters['cHash']);
$cHashParameters = t3lib_div::implodeArrayForUrl('', $cHashParameters);
if ($cacheHashClassExists) {
$cHashParameters = $cacheHash->getRelevantParameters($cHashParameters);
} else {
$cHashParameters = t3lib_div::cHashParams($cHashParameters);
}
unset($cHashParameters['']);
if (count($cHashParameters) == 1) {
// No cHash needed.
unset($paramKeyValues['cHash']);
}
elseif (count($cHashParameters) > 1) {
if ($cacheHashClassExists) {
$paramKeyValues['cHash'] = $cacheHash->calculateCacheHash($cHashParameters);
} elseif (method_exists('t3lib_div', 'calculateCHash')) {
$paramKeyValues['cHash'] = t3lib_div::calculateCHash($cHashParameters);
} else {
$paramKeyValues['cHash'] = t3lib_div::shortMD5(serialize($cHashParameters));
}
}
unset($cHashParameters);
}
if (count($paramKeyValues) == 1) {
$stringForHash = $newUrl;
if (count($this->additionalParametersForChash)) {
$stringForHash .= '|' . serialize($this->additionalParametersForChash);
}
$spUrlHash = md5($stringForHash);
$spUrlHashQuoted = $GLOBALS['TYPO3_DB']->fullQuoteStr($spUrlHash, 'tx_realurl_chashcache');
// first, look if a cHash is already there for this SpURL
list($row) = $GLOBALS['TYPO3_DB']->exec_SELECTgetRows('chash_string',
'tx_realurl_chashcache', 'spurl_hash=' . $spUrlHashQuoted);
$GLOBALS['TEMP2222']['additionalParametersForChash'] = $this->additionalParametersForChash;
$GLOBALS['TEMP2222']['paramKeyValues'] = $paramKeyValues;
if (!is_array($row)) {
// Nothing found, insert to the cache
$data = array(
'spurl_hash' => $spUrlHash,
'spurl_string' => $this->enableChashUrlDebug ? $stringForHash : null,
'chash_string' => $paramKeyValues['cHash']
);
$GLOBALS['TYPO3_DB']->exec_INSERTquery('tx_realurl_chashcache', $data);
}
else {
// If one found, check if it is different, and if so update:
if ($row['chash_string'] != $paramKeyValues['cHash']) {
// If that chash_string is different from the one we want to
// insert, that might be a bug or mean that encryptionKey was
// changed so cHash values will be different now
// In any case we will just silently update the value:
$data = array(
'chash_string' => $paramKeyValues['cHash']
);
$GLOBALS['TYPO3_DB']->exec_UPDATEquery('tx_realurl_chashcache',
'spurl_hash=' . $spUrlHashQuoted, $data);
}
}
// Unset "cHash" (and array should now be empty!)
unset($paramKeyValues['cHash']);
}
else
$GLOBALS['TEMP2222'] = 2;
}
}
Это кусок кода из realurl...
Который проверяет - как то понимаю правильность запрошенного cHash...
Если правлиьно - значит пишет в mysql-табличку, если нет... Ничего...
Как это работает - и как сделать подобную проверку в php-коде?
И вот еще одну функцию нашел:
https://svn.jambage.com:8766/typo3/fholzinger/tx_srfeuserregister/trunk/control/class.tx_srfeuserregister_setfixed.php
public function storeFixedPiVars ($vars) {
// Create a unique hash value
if (class_exists('t3lib_cacheHash')) {
$cacheHash = t3lib_div::makeInstance('t3lib_cacheHash');
$regHash_calc = $cacheHash->calculateCacheHash($vars);
$regHash_calc = substr($regHash_calc, 0, 20);
} else {
// t3lib_div::cHashParams is deprecated in TYPO3 4.7
$regHash_array = t3lib_div::cHashParams(t3lib_div::implodeArrayForU rl('', $vars));
$regHash_calc = t3lib_div::shortMD5(serialize($regHash_array), 20);
}
// and store it with a serialized version of the array in the DB
$res =
$GLOBALS['TYPO3_DB']->exec_SELECTquery(
'md5hash',
'cache_md5params',
'md5hash=' .
$GLOBALS['TYPO3_DB']->fullQuoteStr(
$regHash_calc,
'cache_md5params'
)
);
if (!$GLOBALS['TYPO3_DB']->sql_num_rows($res)) {
$insertFields = array (
'md5hash' => $regHash_calc,
'tstamp' => time(),
'type' => 99,
'params' => serialize($vars)
);
$GLOBALS['TYPO3_DB']->exec_INSERTquery(
'cache_md5params',
$insertFields
);
}
$GLOBALS['TYPO3_DB']->sql_free_result($res);
return $regHash_calc;
}
И так как в выше описанных примерах пока не получилось разобраться нашел такое решение - не идеальное с точки зрения разработки...
$spUrlHashQuoted = $GLOBALS['_GET']['cHash'];
$result = mysql_query("SELECT * FROM tx_realurl_chashcache WHERE chash_string='{$spUrlHashQuoted}' LIMIT 1;");
if ( mysql_num_rows($result) == 0 )
{ // не правильно...
Подскажите пожалуйста как такая операция делается через API-TYPO3?
Вот тоже - про затопление - плагинов через ввод битых cHash
http://forge.typo3.org/issues/29365
---
Dmitry Dulepov
08.10.2013, 13:29
RealURL и core тут не при чем. Если вам передали неправильный uid, вы вызываете $GLOBALS['TSFE']->paheNotFoundHandler('Иди на фиг, хакер поганый!') в своем расширении и все. Никаких проблем.
Вначале думалось проверять useCashHash - в таблицах realurl. Но после нашел - как проверить useCashHash (вернее typolink-ссылки с useCashHash=1) - оказывается через калькуляцию ссылки. Для 404-обычно использую - $GLOBALS['TSFE']->pageNotFoundAndExit();
Работает на vBulletin® версия 3.8.1. Copyright ©2000-2025, Jelsoft Enterprises Ltd. Перевод: zCarot