PDA

Просмотр полной версии : Что происходит в ядре, когда идет запрос битых адресов...


Ивано++
06.07.2013, 01:36
Добрый вечер...

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

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 в минуту с разными комбинациями...
И если у меня будет в БД что-то лишнее писаться, то БД многократно будет увеличиваться...
И человек поставивший цель завалить мой сайт - с ней успешно справиться.

--
Спасибо.

Ивано++
09.07.2013, 11:31
И вот еще вопрос то про "useCacheHash".

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

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

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

Ивано++
10.07.2013, 15:13
Там и не понял как хэш к ссылкам добавляется...
Когда делается прямой заход...

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

Ивано++
10.07.2013, 18:15
Хэш добавляется только при генерации ссылки ядром. В случае 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

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

Ивано++
11.07.2013, 11:08
Но проблема пока осталась.

Мне надо как-то получить уникальное значение правильной страницы (т.е. той которая без 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?

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

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

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

$TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT'] = array (

'init' => array (

'enableCHashCache' => true,


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

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

Ивано++
11.07.2013, 17:08
В общем тогда суть задачи опишу...

Проблема №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-ошибку приходиться устанавливать в ручную - в зависимости от логики, которая там применяться...

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

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

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

Ивано++
11.07.2013, 18:31
Вот еще интересная штука из 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 целиком добавляется.

Ивано++
11.07.2013, 19:51
У вас есть какая-то принципиальная нестыковка, на мой взгляд.

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 - не нашел такого решения...

Ивано++
11.07.2013, 20:02
Вот полный код:

#************************************************* ******************
# Данный файл содержит описание настроек 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]

Ивано++
11.07.2013, 20:17
Одним словом уже запутался крепко...

Ни как не пойму - есть ли простой способ?
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

Ивано++
11.07.2013, 20:40
Вот что получается:

Проверяю в 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);

Ивано++
11.07.2013, 21:22
В общемь... (нет слов)...
Разобрался...

Сделал просто LOAD_REGISTER - отдельно для breadcurmb...

Ивано++
11.07.2013, 21:57
Осталось несколько маленьких вопросиков:

В чем раздница между этими двумя функциями (методами)?
$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.

Ивано++
12.07.2013, 23:17
Эээ.... может быть чего то не понимаю...
Но вот заметил:

установил расширение 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 - должен создаваться только при переходе по ссылкам???

Ивано++
13.07.2013, 00:06
Что - то наверное я ошибся...:)

Ивано++
13.07.2013, 23:26
В общем последний и единственный вопрос из данной темы...

Вот если:
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()

Спасибо...

Ивано++
14.07.2013, 03:02
В общем вот нашел решение проблемы:

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('Иди на фиг, хакер поганый!') в своем расширении и все. Никаких проблем.

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