Какойто бред происходит. Кто что скажет?
из html передается:
...
<form action="test.php" method="GET">
<input type="text" name="www">
...
В test.php :
<?php
print ("$www bla-bla-bla\n");
...
...
?>В браузере: http://xx.xx.xx.xx/test.php?www=test&submit=Submit%21
bla-bla-bla
Куда пропала $www ???
И еще, пхп не понимает почемуто if(isset($xxx)):, else:, endif;
Просто тупо не видет %(
>Куда пропала $www ???Как насчёт register_globals? http://www.php.net/manual/ru/security.globals.php
>И еще, пхп не понимает почемуто if(isset($xxx)):, else:, endif;
>Просто тупо не видет %(Что значит не видит? Пример, пожалуйста. Да, и версию ПХП неплохо бы знать.
>Как насчёт register_globals? http://www.php.net/manual/ru/security.globals.phpСпасибо за ссылку, не знал. Стояла, ясное дело, в Off
>Что значит не видит? Пример, пожалуйста. Да, и версию ПХП неплохо бы
>знать.php 4.4.4 Вот примерчик:
<html>
...
<?
if(isset($submit)):
print ("Ok");
else:
?>
...
<form actin=this.php...>
<input type=submit...>
...
<?
endif;
?>
...
</html>
>Спасибо за ссылку, не знал. Стояла, ясное дело, в OffДесять раз подумай, прежде чем включать эту опцию. Соображения безопасности почти всегда важнее кажущегося удобства написания программ.
>php 4.4.4 Вот примерчик:
>...Ну и? Как этот пример "тупо не видит" конструкции языка? Неужели выполняются операторы и после if, и после else? Не верю.
Наверое, дело в тех же register_globals. Ведь переменная $submit - это, вероятно, тот самый замечательный submit=Submit%21, или я ошибаюсь?
>Ну и? Как этот пример "тупо не видит" конструкции языка? Неужели выполняются
>операторы и после if, и после else? Не верю.нет, не выполнялся код после if
>Наверое, дело в тех же register_globals. Ведь переменная $submit - это, вероятно,
>тот самый замечательный submit=Submit%21, или я ошибаюсь?Да, Вы совершенно правы, дело было в register_globals, сейчас все работает. Сервер локальный, поэтому включение опции ничем не грозит.
Спасибо.
>[оверквотинг удален]
>>операторы и после if, и после else? Не верю.
>
>нет, не выполнялся код после if
>
>>Наверое, дело в тех же register_globals. Ведь переменная $submit - это, вероятно,
>>тот самый замечательный submit=Submit%21, или я ошибаюсь?
>
> Да, Вы совершенно правы, дело было в register_globals, сейчас все работает.
>Сервер локальный, поэтому включение опции ничем не грозит.
>Спасибо.Давно я PHP не занимался, но по памяти register_globals в OFF это уж точно. А к гету обращаются $HTTP_GET_VARS['www'];
>Давно я PHP не занимался, но по памяти register_globals в OFF это
>уж точно. А к гету обращаются $HTTP_GET_VARS['www'];Да, видно, что давно ;) Теперь обычно обращаются $_GET['www'] или $_REQUEST['www'].
>>Давно я PHP не занимался, но по памяти register_globals в OFF это
>>уж точно. А к гету обращаются $HTTP_GET_VARS['www'];
>
>Да, видно, что давно ;) Теперь обычно обращаются $_GET['www'] или $_REQUEST['www'].Ну и ладно. На нашем предприятии всё равно Oracle и странички мы клепаем в HTMLDB. Изысков конечно нет, но то что я делаю за 15 минут, в PHP я просто упрусь делать.
Что можно сказать, поздравляю с присоединением к толпе пыхобыдлокодеров. Если захотите когда либо вырасти из этого в вебдевелоперы, то читайте доку к языку, изучите основы web-безопасности и не используйте порочных практик.
Может я , конечно. что-то путаю
но если не ошибаюсь, то для ввода переменных лучше делать метод POST
насколько мне известно, строка GET-метода ограничена длиной 256 символов, в то время как у POST размер неограничен...ну почти не ограничен..
ещё может быть проблема...вообщем если несколько одноимённых форм...
>Может я , конечно. что-то путаю
>но если не ошибаюсь, то для ввода переменных лучше делать метод POSTнет
>насколько мне известно, строка GET-метода ограничена длиной 256 символов,
нет
>ещё может быть проблема...вообщем если несколько одноимённых форм...
нет
>[оверквотинг удален]
>
>нет
>
>>насколько мне известно, строка GET-метода ограничена длиной 256 символов,
>
>нет
>
>>ещё может быть проблема...вообщем если несколько одноимённых форм...
>
>нет1)А если передовать имя пользователя и пароль, так тоже будите использовать GET?
2) И еще может лучше так писать:
if(isset($submit) && strlen($submit)>0)
{ //
}
>1)А если передовать имя пользователя и пароль, так тоже будите использовать GET?Утверждение "для ввода переменных лучше делать метод POST" - неверно. Какое слово непонятно?
>2) И еще может лучше так писать:
>
>if(isset($submit) && strlen($submit)>0)
>{ //
>}Зачем?
>>if(isset($submit) && strlen($submit)>0)
>>{ //
>>}
>
>Зачем?
>>if(isset($submit) && strlen($submit)>0)
>>{ //
>>}
>
>Зачем?У меня была, такая проблема, при передачи значения из формы,т.е.
$ftel =strip_tags($HTTP_POST_VARS['tel']); //это передаю телефон
if (isset($ftel) // это проверяю есть ли он
{
сюда попадаю если даже телефон не установлен
}а так
$ftel =strip_tags($HTTP_POST_VARS['tel']); //это передаю телефон
if (isset($ftel && strlen($submit) // это проверяю есть ли он
{
сюда попадаю если телефон установлен
}Извините за неточность.
P.S. можно через _GET
register_globals=offОтрывок из книги:Профессиональное PHP программирование Второе издание
Л.Аргерих, В.Чой..Глава: Небезопасность register_globals
Одной из самых удобных и опасных характеристик РНР является возмож-
ность пользоваться переменными, которые не были явно определены. Это
904 Глава 23. Система безопасности
очень популярная функция РНР, но в сочетании с установкой register_globals
может создать проблему безопасности вашего приложения.
register_globals
Это, вероятно, самая опасная из всех настроек РНР. Если она имеет значе-
ние on (установка по умолчанию вплоть до РНР 4.1), а не off (значение по
умолчанию начиная с РНР 4.2), то переменные EGPCS регистрируются как
глобальные. С этим связано несколько угроз.
Прежде всего, это означает, что пользователю не надо проверять, откуда по-
ступила переменная (от POST, GET или cookie), поэтому значения перемен-
ных могут быть поддельными. Одно это обстоятельство вызывает большин-
ство проблем со сценариями РНР. Если вы установили значение этой пере-
менной равным off (рекомендуется), то включите tгасk_vars в on....