Как, в случае ввода пользователем в текстовое поле типа <input type =text> всего чего угодно, только не какого-то числа, выводилось сообщение об ошибке и ничего далее не делалось, т. е. чтобы в поле можно было ввести только число. [Ответ]

fuhrer
это не php а javascript...

з.ы. проверяем, что введено...
1. число - ничего не далаем
2. не число - выводим сообщение об ошибке [Ответ]

Перед отправкой данных с формы делать проверку строки инпута. [Ответ]

to loshadka Эх, раньше меня запостил [Ответ]

Ray79 [Ответ]

а кто помешает пользователю отправить нечисло и похакать всенасвете?

в php на сервере тоже нужно проверять переменные.
хотя бы так :
$num=(int)$num; [Ответ]

netwind учимя читать вопрос... [Ответ]

Сообщение от :
это не php а javascript...

Как так не php, прог уже почти готов и я думал (во всяком случае надеялся), что пишу его на php. [Ответ]

fuhrer
ты пишешь никому ненужный курсовик или реальное приложение для интернета?
это число потом участвует в дальшейших запросах к БД, вычислениях или программной логике?

хотелось бы чтобы программисты понимали, что яваскрипт спасет от неаккуратного ввода, но не от злонамеренного хакера. [Ответ]

Сообщение от :
это число потом участвует в дальшейших запросах к БД, вычислениях или программной логике

Это число должно занестись в мускуловскую базу в поле, которое имеет тип BIGINT(15). [Ответ]

fuhrer
тогда перед занесением его в базу нужно сделать проверку, вот тут как раз php, http://php.net/is_int/ [Ответ]

ну вот, если не перепроверить значение и в php - получишь типичную ошибку SQL-injection. об это много понаписано.

fuhrer товарыщи тоже дело говорят:
обычно делают проверку данных на javascript на клиентской стороне, еще до отсылки на сервер, чтобы пользователю по 10 раз не запрашивать страничку.
Но и проверками на стороне php пренебрегать не следует.
Злонамеренный пользователь может отключить жаваскрипт и запихать тебе в базу
данных каких захочет.

простая строчка
$num=(int)$num;
гарантирует что у тебя в переменной будет число (или 0, что не так уж плохо)
loshadka
учимся не только читать, но и анализировать вопрос ). [Ответ]

loshadka
Большой Danke. Заработало... [Ответ]

netwind, а (int)$num - это то же самое, что intval($num) ?

ну а для того, чтобы наверняка прекратить дальнейший вывод, есть функция die() [Ответ]

Сообщение от yujanin:
ну а для того, чтобы наверняка прекратить дальнейший вывод, есть функция die()

сам понял что сказал? [Ответ]

yujanin ну да, практически то же самое, но приведение типов смотрится короче и благороднее.
maximn просто такова сложившая практика php,
ленивые программисты вместо обработки ошибок приводят типы и пихают везде die(), после обнаружения злонамеренных действий скрипты больше ничего не делают а просто мрут [Ответ]

Сообщение от maximn:
сам понял что сказал?

понял... функция die() останавливает php-процессор. так тебе понятнее? [Ответ]

Сообщение от netwind:
maximn просто такова сложившая практика php,
ленивые программисты вместо обработки ошибок приводят типы и пихают везде die(), после обнаружения злонамеренных действий скрипты больше ничего не делают а просто мрут

не обязательно. можно и обработку событий, ошибок сделать, и логи писать и всё что угодно. die() в конце просто останавливает скрипт - и это хорошая практика. [Ответ]

Сообщение от yujanin:
понял... функция die() останавливает php-процессор. так тебе понятнее?

зачем ему "прекращать дальнейший вывод"?

от чего ты его защитить решил?

$num = intval($_POST['num']);
mysql_query("UPDATE my_tbl SET num='".$num."' WHERE ...")
//и зачем вот тут die()!?

или такой вариант:

$num = intval($_POST['num']);
if (!$num) {
//а тут он зачем?
} else {
mysql_query("UPDATE my_tbl SET num='".$num."' WHERE ...")
}

или ты придумал новые типы инджекшена?

ЗЫ НЕЗАВИСИМО от того что прислал пользователь, скрипт НЕ должен аварийно и молча завершаться НИКОГДА [Ответ]

страшно далеки вы от народа) расскажите почему не должен?
вот сейчас посчитал в vbulletin 26 раз die.

представь что ты пишешь небольшую модификацию незнакомого проекта,
и после твоего кода там могут быть еще какие-то вычисления с той же переменной.
die() гарантирует скрипт точно остановится и даже попытается в html вывести ошибку. [Ответ]

будем считать что это мое имхо, каждый ****** по-своему..

если не сложно, сосчитай, сколько раз в vBulletin встречается 'at' и напиши сюда. я бы сам посчитал, но мне его качать нужно, а раз уж он у тебя стоит..

ЗЫ не написать мне своего vBulletin'a.. мечты разбиты вдребезги.. [Ответ]

netwind обработка ошибок должна быть корректной... а не просто die()...

должен быть нормальный и человекопонятный вывод сообщения... [Ответ]

кто должен? кому? никому я не должен)

если все данные уже проверены в жавскрипте, то можно спокойно помирать, хакиров за людей не считаем)

maximn "at" это что вообще ?подавление ошибок @ ? - очень много, пальцев не хватит.

вообще в vbulletin есть более приличная обработка нефатальных ошибок: мылит на почту или в файл пишет.
как пойдет мылить ошибки админу, только успевай чистить.
кроме того своя система отладки.
это, скорее, исключение и общей массы движков. [Ответ]

ну например :
if (!defined('THIS_SCRIPT') AND strpos(strtolower($script), 'global.php') !==
false)
{
die('<p><strong>Critical Error</strong><br />global.php must not be
called directly.</p>');
}


Ну в каком страшном сне юзер будет вызывать init.php ??
Die и все тут! [Ответ]

Сообщение от netwind:
ну например :
if (!defined('THIS_SCRIPT') AND strpos(strtolower($script), 'global.php') !==
false)
{
die('<p><strong>Critical Error</strong><br />global.php must not be
called directly.</p>');
}


Ну в каком страшном сне юзер будет вызывать init.php ??
Die и все тут!

да, это случай №2 когда использование die() необходимо. т.е. когда движок подгружает нужные модули в зависимости от раздела через require('chapter_1.php')

случай №1 когда без die() нельзя обойтись, это header+die

про 'at'ы (собаки) в vBulletin - самого думаю улыбнуло =)

зы всё имхо [Ответ]

так я и не понял чем die тебе не угодил.
die это скорее sanity check, чем обработка ошибок пользователя и если все перечитать сначала, то применяется очень даже к месту.

в приведеном мною коде, ничего не мешает вывести ошибку красиво и тд.
просто вызов модуля прямо браузером - абсолютно ненормальный случай,
наверняка хакерский, возиться c этим случаем никто не хочет. [Ответ]

Сообщение от loshadka:
netwind обработка ошибок должна быть корректной... а не просто die()...

должен быть нормальный и человекопонятный вывод сообщения...

мы немного о разных вещах. die() - это не обработчик ошибок. это должна быть последняя строка в любом обработчике ошибок. это, как сказал netwind, sanity check, и просто хорошая практика. а на экран выводится wrapper какой уж хочешь. но задача программиста с точки зрения безопасности кода - убедиться, что вывод будет однозначно остановлен после выброса ошибки. [Ответ]

Сообщение от maximn:

$num = intval($_POST['num']);
mysql_query("UPDATE my_tbl SET num='".$num."' WHERE ...")

или такой вариант:

$num = intval($_POST['num']);
if (!$num) {
//а тут он зачем?
} else {
mysql_query("UPDATE my_tbl SET num='".$num."' WHERE ...")
}

во первых, intval("blabla"), например, будет равен 0 (а не NULL, как, судя по !$num, думаешь ты). откуда ты знаешь, что у тебя в таблице нет поля num = 0?. во-вторых, и в первом и во втором случае (из-за упомянутого выше нуля после intval) нужно ввести проверку на $num > 0. и если будет равно нулю, то нужно выбросить ошибку и остановить скрипт (с оформлением или без - это уже твоё решение). отчасти потому, что после [php]else {
mysql_query("UPDATE my_tbl SET num='".$num."' WHERE ...")
}[/php]

может идти ещё до хера стейтментов в скрипте. при этом у тебя продолжает идти вывод - но уже с одной неправильной переменной и с одним пропущенным sql-стейтментом. как это скажется в дальнейшем на исполнении скрипта (особенно, если скрипт большой) - одному богу известно. поэтому нельзя уповать на то, что в дальнейшем $num не пригодится или что и без этого UPDATE всё нормально прокатит - нельзя. нужно обработать ошибку.

Сообщение от :
ЗЫ НЕЗАВИСИМО от того что прислал пользователь, скрипт НЕ должен аварийно и молча завершаться НИКОГДА

так никто и не говорит, что молча и аварийно нужно. выкинуть ошибку на экран (можно даже хорошо оформленную), что мол так и так. а потом - сдохнуть. есть вещи, которые нормальный пользователь не введёт никогда (потому как нормальный пользователь бродит по ссылкам, а не будет менять значения в query string или в формах, подставляя всякие там ' и UNION) - и задача хорошего программиста, заботящегося о безопасности - пресекать такие попытки самыми строжайшими способами. [Ответ]

Сообщение от yujanin:
во первых, intval("blabla"), например, будет равен 0 (а не NULL, как, судя по !$num, думаешь ты). откуда ты знаешь, что у тебя в таблице нет поля num = 0?. во-вторых, и в первом и во втором случае (из-за упомянутого выше нуля после intval) нужно ввести проверку на $num > 0. и если будет равно нулю, то нужно выбросить ошибку и остановить скрипт (с оформлением или без - это уже твоё решение).

1. RTFM на тему оператора "!" И приведения типов. йа ару..
2. да мне пофиг есть там num=0 или нет, мы тут ввод пользователя проверяем, если ты не в курсе
2. $num > 0 - слов нет, это что? лирическое отступление автора?

Сообщение от yujanin:
отчасти потому, что после [php]else {
mysql_query("UPDATE my_tbl SET num='".$num."' WHERE ...")
}[/php]

может идти ещё до хера стейтментов в скрипте. при этом у тебя продолжает идти вывод - но уже с одной неправильной переменной и с одним пропущенным sql-стейтментом. как это скажется в дальнейшем на исполнении скрипта (особенно, если скрипт большой) - одному богу известно. поэтому нельзя уповать на то, что в дальнейшем $num не пригодится или что и без этого UPDATE всё нормально прокатит - нельзя. нужно обработать ошибку.

уповать не надо, надо проверять, обрабатывать, но не die() офигивающему пользователю

Сообщение от yujanin:
так никто и не говорит, что молча и аварийно нужно. выкинуть ошибку на экран (можно даже хорошо оформленную), что мол так и так. а потом - сдохнуть. есть вещи, которые нормальный пользователь не введёт никогда (потому как нормальный пользователь бродит по ссылкам, а не будет менять значения в query string или в формах, подставляя всякие там ' и UNION) - и задача хорошего программиста, заботящегося о безопасности - пресекать такие попытки самыми строжайшими способами.

никто не говорит? значит мне показалось, наверное
ты плохо знаешь пользователей, будут они и квоты и даблквоты пихать поверь.

пойми - от пользователя НЕ может прийти данных вызывающих ошибку. всё, точка. всё что пришло - это заебатые данные априори. это проблема программиста их проверять и обрабатывать. но если они пришли, то так и надо - этого хочет пользователь. и если он хочет искать по ' UNION .., значит ты ДОЛЖЕН искать по ' UNION ... Если он хочет логин ' or 1=1 , то у него ДОЛЖЕН быть именно такой логин.

Ошибок ввода не бывает, бывают ошибки их обработки. [Ответ]

лол... ну ты и демагог.

покажи хоть один нормальный действующий проект на php, который ты написал... просто интересно. [Ответ]