13 декабря 2007 г. PHP

Пора делать свой код совместимым с PHP 6

Журнал phpINSIDE призывает делать свой код совместимым с PHP6.

Авторы блога "Making the web" предлагают уже сейчас писать код с учётом требований PHP6.
Для этого необходимо как минимум:
  • забыть про register_globals
  • перестать использовать magic_quotes
  • не использовать длинные имена глобальных массивов (пример: $HTTP_POST_VARS)
  • в регулярных выражениях начать использовать preg вместо ereg
  • и не инициировать создание объекта по ссылке
Да, действительно PHP6 не за горами, и мы сейчас попробуем перевести код с учетом требований PHP6.

Использование глобальных переменных (Register_Globals)

Наверное, наиболее спорным моментом в разработке PHP стала замена значения по умолчанию для опции register_globals с ON на OFF в версии » 4.2.0. Большинство пользователей доверились разработчикам, даже не зная, что это за опция и как она влияет на работу PHP. Эта страница документации призвана показать, как эта настройка сочетается с вопросами безопасности при разработке приложений. Следует понимать, что сама по себе эта опция никак не влияет на безопасность, ургозу представляет некорректное использование предоставляемых ею возможностей.

В случае, если значение параметра register_globals ON, перед выполнением вашего кода будут инициализированы различные переменные, например, переменные, переданные при отправке формы. Также, учитывая тот факт, что PHP не требует инициализации переменных, написать потенциально опасный код очень легко. Это было очень спорным решением, но общество разработчиков PHP решило изменить значение по умолчанию этой директивы на OFF. В противном случае при написании кода разработчики не могли бы с уверенностью сказать, откуда пришла та или иная переменная и насколько она достоверна. До такого нововведения переменные, определяемые разработчиком внутри скрипта, и передаваемые пользователем внешние данные могли перемешиваться.

Подробнее: http://ru2.php.net/register_globals

Как изменить значение register_globals "ON" на "OFF"?

Пишем в .htaccess (файл дополнительной конфигурации сервера Apache)

php_flag register_globals off

После того как вы это сделали, данные введенные пользователем не будут автоматически переведены в переменные и будут храниться в глобальных переменных $_GET, $_POST и т.д. Например: было - $page стало - $_GET['page'] или было - $login, стало - $_POST['login'].

Волшебные кавычки (magic_quotes)

По многим причинам. Самая очевидная - логическая. "Волшебные кавычки" добавляют слеши не там, где они нужны - при составлении запроса, а еще до попадания в скрипт! Но ведь данные совсем не обязательно после этого будут вставляться в запрос. Может быть, их придётся выводить пользователю, и слеши будут только мешать. Плюс к тому, добавленные слеши помешают, к примеру, правильно проверить длину введённой строки. К тому же, прослешивать нам надо не только пришедшие от пользователя данные, а вообще любые, вставляемые в запрос - многим этот очевидный факт даже не приходил в голову! Список можно продолжать, но вывод один: добавлять слеши надо не автоматом, без разбору, до начала выполнения скрипта, а только там, где действительно надо – при составлении запроса.
Есть и ещё одна причина: при использовании кодировки Unicode, которая приобретает всё большую популярность, а со временем займёт доминирующее положение в веб, волшебные кавычки могут попросту испортить текст, приняв часть мультибайтной строки за спецсимвол.

Среди причин, по которым не стоит полагаться на "волшебные кавычки", есть ещё одна. Весьма маловероятная, но всё же. К "волшебным кавычкам" относится на самом деле не две директивы, а три. Третья - magic_quotes_sybase. Мало того, что она вместо слеша добавляет кавычку - так она ещё и отменяет действие magic_quotes_gpc. Если каким-то чудом обе эти директивы имеют статус 'on', то последняя не сработает! То есть, полагаясь на "волшебные кавычки", мы в этом случае получим все прелести неправильно составленных запросов. Вообще, чисто теоретически, надо учитывать наличие этой директивы, поскольку она преподносит ещё и такой сюрприз, как... изменение поведения функций addslashes и stripslashes! Если magic_quotes_sybase = on, то эти функции начинают вместо слеша добавлять и удалять одинарную кавычку соответственно.

Подробнее: http://www.php.net/manual/ru/ini.core.php и http://ru.wikipedia.org/wiki/Htaccess

Как отключить?

Пишем в .htaccess (файл дополнительной конфигурации сервера Apache)

php_flag magic_quotes_gpc 0
php_flag magic_quotes_runtime 0
php_flag magic_quotes_sybase 0

Для запросов в БД MySQL использовать mysql_real_escape_string().

Пример:

Следует помнить, что применять её можно только после установления соединения с базой.
Эта функция делает гораздо больше, чем устаревшие addslashes и mysql_escape_string. Во-первых, она облегчает ведение и чтение логов mysql, заменяя, например, символ перевода строки на "n" и некоторые другие символы на escape-последовательности. Во-вторых, и самое главное - она корректно работает с многобайтными кодировками, принимая во внимание текущую кодировку MySQL и не портит, таким образом, тексты в кодировке Unicode.

Вот еще пример:

Более подробнее о "Волшебных кавычках" на сайте phpfaq.ru

<span style="color:#BCBCBC;">Завтра постараюсь рассказать почему не следует использовать длинные имена глобальных массивов такие как: "$HTTP_POST_VARS", а также почему  в регулярных выражениях надо начинать использовать preg вместо ereg и не инициировать создание объекта по ссылке.</span>

Комментарии

Низнаю как все, но в подобном стиле пишу всегда....

Аналогично

регулярки пока незнаю поэтому ereg или preg мне всёравно а вот остальное я правильно знач делаю

Регулярки незаменимы для работы с текстом, да и вообще по жизни пригодится.
Я при помощи их фильтрую файлы и правлю текст в редакторах, очень удобно и экономит кучу времени!

А я тоже не юзаю практически негде регулярок, а текст правлю строковыми функциями. По идее, они работают малость шустрее, чем регулярки. Хотя и без регулярок часто не обойтись, например при проверке мыла.

Где-то шустрее, а где-то и нет. Зато удобство и гибкость какая, единственный минус - поначалу сложно освоить.

Вот-вот. Меня эта сложность и отпугивает от глубокого их изучения. Но это до того момента, пока они мне не понадобятся критически.
Сейчас ещё попробую найти (если такая имеется) обещанную тобою запись про использование preg вместо ereg.

я регулярки уже пытаюсь освоить

обещанную тобою запись про использование preg вместо ereg

Не, я не писал пост про это, но ты легко найдешь в гугле думаю...

Troy, правильно, однако важно понимать что надо учить PCRE, а не POSIX. Хотя у них есть сходство...

а подробнее ? мне эти 2 слова неочём не говорят

http://ru.wikipedia.org/wiki/PCRE
http://ru.wikipedia.org/wiki/POSIX

Оставьте свой комментарий

Markdown