Спамят битым POST

[Toxic_Cat]

Приветствую.

Столкнулся с такой проблемой, скрипт комментов, мне постоянно приходит странный $_POST, который "обрывается". Допустим я сделаю serialize этого $_POST, тогда будет что-то вида:

a:13:{s:4:"text";s:139:"Oh dear, and i wentinto the cold. Jesus. <a href= http://spam-site.com/186.html >

Ладно, я заменил serialize на:

	$save_original = '';
	foreach ( $original as $key => $val ) {
		$save_original .= $key . '===' . $val . "|||\n";
	}

И опять фигня! Мне выдает:

text===<a href= http://spam-site.com/282.html >

MySQL, куда все это сохраняется в UTF-8, все скрипты вроде как UTF-8 без BOM...

В чем может быть трабл? Я не понимаю, как так может быть, что $_POST передается с кучей переменных, которые спокойно проходят isset(); и фильтры но при попытке "увидеть" этот $_POST превратив его в строку он обрубается банально! И таким же обрубком он сохраняется в MySQL! Причем PHP видит закрывающий тег </a>! Но при сохранении в базу его уже там нет, в итоге в админке у меня еще и гемор с отображением из-за незакрытого тега...

Я могу лишь догадываться, что там есть какой-то спецсимвол... Может кто сталкивался с этой проблемой? А то спамят, блин, нонстоп вот такой конструкцией и я никак не могу проследить...

Подскажите, плиз...

 

[Single]

Возможно допустимый размер данных для ячейки в таблице не позволяет записать все данные.
Не помешает ознакомиться с ссылка.

 

[Toxic_Cat]

Возможно допустимый размер данных для ячейки в таблице не позволяет записать все данные.
Не помешает ознакомиться с ссылка.

Остальные запросы отлично пишутся через serialize(); и через костыль, полностью со всеми переменными. Поле имеет тип longtext

 

[KorP]

как исходный пост то выглядит? может там мусор какой есть?

 

[Toxic_Cat]

Так в том то все и дело, что я не знаю, что именно мне шлют изначально... Я не могу $_POST запрос сохранить и посмотреть... Может кто предложит варианты его сохранения?

 

[KorP]

Так может они и не шлют больше ничего на самом деле? ))

 

[Toxic_Cat]

Так может они и не шлют больше ничего на самом деле? ))

Еще как шлют, иначе бы не прошла банальная проверка

if ( !isset ( $_POST['c'] ) ) {
 die('Dead Post');
}

Но запрос проходит эту проверку! А при serialize(); никакой переменной $_POST['c'] не выводится... Потому, что все обрывается на переменной $_POST['text']...

 

[Вурдалак]

Похоже на то, что происходит несоответствие указанной кодировки (UTF-8) и фактической кодировки сообщения. MySQL имеет привычку просто не сохранять дальше.

 

[KorP]

Еще как шлют, иначе бы не прошла банальная проверка

if ( !isset ( $_POST['c'] ) ) {
 die('Dead Post');
}

Но запрос проходит эту проверку! А при serialize(); никакой переменной $_POST['c'] не выводится... Потому, что все обрывается на переменной $_POST['text']...

а мы догадаться должны были? так же как и угадать что шлётся в $_POST['c']?

Возможно и правда дела в кодировке, попробуй в файл сохранять

 

[Toxic_Cat]

а мы догадаться должны были?

Сорри :S

Похоже на то, что происходит несоответствие указанной кодировки (UTF-8) и фактической кодировки сообщения. MySQL имеет привычку просто не сохранять дальше.

Да, я тоже склоняюсь к проблемам с кодировкой... Сделал сохранение данных в файл... Осталось ждать )

 

[whirlwind]

MySQL имеет привычку просто не сохранять дальше.

какая конкретно версия mysql просто не сохраняет данные дальше?

 

[Toxic_Cat]

какая конкретно версия mysql просто не сохраняет данные дальше?

5.1.55

 

[Вурдалак]

whirlwind, 5.1.40, к примеру.

 

[Viktor_Rez]

Ох, заслать тебе постом a-z элементарно. - Избавляемся от таких переменных.
Надо проверять не только на наличие переменной, но и её значение. - Допилим.
Для вставки в базу надо юзать prepared statements. Или mysql_escape_string. Хотя первое более логичней.
Для дебага юзаем var_dump().

 

[Toxic_Cat]

Ох, заслать тебе постом a-z элементарно. - Избавляемся от таких переменных.
Надо проверять не только на наличие переменной, но и её значение. - Допилим.
Для вставки в базу надо юзать prepared statements. Или mysql_escape_string. Хотя первое более логичней.
Для дебага юзаем var_dump().

Нельзя a-z, мне надо Японские буквы (они же иероглифы) допускать.
Значения переменной как раз проверяются, делаются всякие htmlspecialchars(); trim();, проверка на длинну (min, max). Все эти проверки переменные проходят. Причем я не стесняюсь юзать медленные mb_ функции, с заданной UTF-8 кодировкой (не везде правда).
У меня используется MySQL_Real_Escape_String();
var_dump(); выводит инфу в браузер... Для своего личного дебага предпочитаю print_r, который обёрнут в <pre></pre>

Короче это все работало уже несколько лет, вот недавно такой спамер объявился, который миксует в посте кодировки (спамит xRumer'ом). Сейчас он резко куда-то пропал, наверное читает этот форум Как только он запостит свой коммент, я быстро его сохраню автоматом через file_put_contents(); и посмотрю...

 

[Viktor_Rez]

Имена переменных - От $_POST["a'] до $_POST["z"].

 

[whirlwind]

Toxic_Cat
Viktor_Rez

Как воспроизвести ситуацию?

 

[Вурдалак]

$s = 'test тест test'; // UTF-8
$s = iconv('utf-8', 'windows-1251', $s);

// ...

mysql_set_charset('utf8');
mysql_query(sprintf("INSERT INTO `table` (`name`) VALUES ('%s')", mysql_escape_string($s)));

В таблицу попадёт «test ».

А ты о чём подумал?

 

[zerkms]

Вурдалак
В чём фича делать mysql_set_charset, если всё равно функция экранирования потом "не та"?

 

[fixxxer]

Первым делом, чтобы исключить всякую ерунду, надо включить STRICT_ALL_TABLES (вообще говоря, включать его надо всегда).