|
Все в этой жизни
меняется. Меняются и средства программирования, не всегда в лучшую сторону, но по
заверениям разработчиков именно туда. Дальнейшее развитие PHP ведет в сторону
отказа от регистрации глобальных переменных по умолчанию. Говорят, что это усилит
безопасность скриптов... Ну что ж, посмотрим... Раньше опции register_globals
находилась в положении on, что означало простоту использования внешних переменных,
передаваемых скрипту. Это был один большой плюс PHP - значительно упрощалось
кодонаписание. Конечно, это было не безопасно: всегда была вероятность взлома
системы при плохо продуманном использовании переменных (не предопределенных самим
скриптом), но вопрос состоял именно в человеческих ошибках, а не в ошибочности
подхода к определению переменных. Теперь уже почти везде в настройках опция
register_globals находится в выключенном положении. Что это означает для нас? Это
значит, что большинство скриптов (особенно бесплатных) не будут работать в новых
реалиях. Задача переконвертации скриптов, приведения их к новому стандарту становится
нашей небольшой головной болью. Конечно, еще не везде отключена регистрация
глобальных переменных, да и на домашних серверах для тестирования собственных
веб-программ вы наверняка опцию register_globals оставили в положении "включено".
Но чем раньше мы будем думать о будущем, тем раньше будущее подумает о нас! ;)
(© Art1st)
Итак, исходные
начальные наши условия сводятся к тому, что у нас есть скрипт, работоспособный в
условиях включенной опции register_globals, ну а сама опции на сервере находится
в положении "off". Мы рассмотрим 3 варианта возможных наших действий в данной
ситуации:
[1] Первый вариант самый трудоемкий,
но самый действенный и самый правильный. Наши действия сводятся к банальной замене
всех переменных, получаемых извне скриптом, на их аналоги в "суперглобальных"
массивах php. Например, скрипт получает из cookies переменную с именем name: ранее
для использования переменной было достаточно написать $name, теперь же следует
писать $HTTP_COOKIE_VARS['name'] (применимо ко всем версия php) или $_COOKIE['name']
(только для версий php "старше" 4.1). Преимуществом данного варианта является
синтаксическая и морфологическая корректность скрипта, а также гарантированная его
работа в будущем при любых значениях опции register_globals; кроме того, скрипт
для программиста становится более информативным и читаемым. К недостаткам данного
способа относится высокая трудоемкость и отчуждение старого доброго программирования
на php, когда не надо было заморачиваться по этим вопросам ;).
[2] Второй вариант сводится к
примитивному изменению настроек. Судя по документации к php значение опции,
описанной в php.ini можно сменить функцией ini_set, а точней так: ini_set
('register_globals','1'); Только вот почему-то это не работает... (Испытания
проводились на: OS: WinXP Proffesional SP0 ;) - Server: Apache 2.0.43 -
PHP: 4.2.3 (CGI) Если кто знает почему, объясните, plz!) Другим путем
изменения настроек является файлик .htaccess в корне сайта с содержанием:
'php_flag register_globals on' - но и это почему-то не работает... хм... 8(
Вообщем, в теории плюсом этого варианта является его простота и доступность, а
к минусам можно отнести снижение уровня защищенности скрипта и сомнительность
работоспособности на разных хостингах...
[3] Третий вариант является также
достаточно простым и довольно-таки распространенным. Он основан на использовании
функции extract, которая будет регистрировать для нас переменные со старыми
именами из суперглобальных массивов. Если вы используете php версии выше 4.1, то
вам будет достаточно в самом начале скрипта разместить следующий код:
<?
extract ($_SERVER);
extract ($_GET);
extract ($_POST);
extract ($_COOKIE);
extract ($_FILES);
extract ($_ENV);
extract ($_SESSION);
?>
Есть более универсальный аналог
подходящий для любых версий php-интерпретатора:
<?
extract ($HTTP_SERVER_VARS);
extract ($HTTP_GET_VARS);
extract ($HTTP_POST_VARS);
extract ($HTTP_COOKIE_VARS);
extract ($HTTP_POST_FILES);
extract ($HTTP_ENV_VARS);
extract ($HTTP_SESSION_VARS);
?>
Достоинством данного способа
стоит считать его относительную простоту + ограничение нагрузок на http сервер
(неиспользование .htaccess), главным же промахом можно выявить снижение уровня
защищенности скрипта, а также необходимость повторять эту процедуру для каждого
php - файла.
Какой вариант выбрать вам? Выбирайте
сами, что вам удобно и доступно! Спасибо за внимание! Ждите новых статей... ;)
|
