Pojďme se podívat na to, jaké nejčastější problémy související s
konfigurací PHP nás mohou potkat. Uvidíte, že to může být poměrně
zábavné a že odlišné nastavení mohlo a může způsobit zajímavé věci. Ale
popořadě.
Register_globals
Asi nejpopulárnější volba php, nebo aspoň v minulosti
nejdiskutovanější je bezesporu register_globals. Pokud je nastavena na
ON, tedy zapnuto, jsou automaticky proměnné z polí $_GET[], $_POST[] a
$COOKIE[] k dispozici jako globální. Malá ukázka to osvětlí; dejme
tomu, že příklad níže je uložen ve skriptu test.php a volán jako
test.php&id=5:
echo
"Register_globals je nastaveno na: ".ini_get('register_globals')."<BR>\n";
echo "Pomocí pole \$_GET je vždy k
dispozici: ".$_GET["id"]."<BR>\n";
echo "Jako globální proměnná: ".$id."<BR>\n";
Jestliže bude v php.ini register_globals ZAPNUTO, bude výstup tento:
Register_globals je
nastaveno na: 1
Pomocí pole $_GET je vždy k dispozici: 5
Jako globální proměnná: 5
Jestliže však bude v php.ini register_globals VYPNUTO, bude výstup
tento:
Register_globals je
nastaveno na:
Pomocí pole $_GET je vždy k dispozici: 5
Jako globální proměnná:
Jak tedy vidíte, je v případě zapnuté volby register_globals
proměnná $_GET["id"] k dispozici i jako $id.
Pozn.: Pokud si to chcete vyzkoušet
doma, budete mezi jednotlivými spuštěními skriptu muset upravit soubor
php.ini. Pokud vám běhá php jako modul serveru Apache, budete muset navíc ještě restartovat Apache, a
to z toho prostého důvodu, že php.ini se v takovém případě načítá pouze
při startu webového serveru.
Možná si kladete otázku, proč je kolem toho takový randál? Není to
snad poměrně jasné? Rámus kolem této konfigurační volby vznikl ve
třetím čtvrtletí roku 2000, kdy byla vydána verze PHP 4.2.0. Tato verze
totiž (a později každá následující) jakožto výchozí volbu po instalaci
PHP poprvé nastavila register_globals na VYPNUTO. Uživatelům, kteří
spoléhali na automatickou registraci proměnných (to je ten PRVNÍ z
případů výše), tak rázem přestaly fungovat některé skripty.
Byla to vzrušující doba. Jedni reagovali obviňováním autorů PHP,
jiní nahlašovali chybu do bugreportů, další požadovali ihned globální
proměnné zpět ZAPNOUT a ještě jiní uvažovali o přechodu na jiný jazyk,
protože tohle pro ně bylo prostě příliš...
Pozn.: Dnes je situace taková, že na
"klasických" hostinzích budete mít nejspíš register_globals vypnuté s
tím, že na požádání vám ji zapnou. Chtít to zapnout je ale velmi špatný
nápad, viz níže.
Fakt je, že autoři PHP měli ke změně výchozího chování programu
poměrně pádné důvody. Ze stejných důvodů byste měli psát skripty tak,
aby fungovaly BEZ nutnosti registrace globálních proměnných. Takže, ty
důvody jsou dva:
- Výkonový - Jestliže skript musel zaregistrovat proměnné jako
globální, zabralo to pochopitelně nějakou dobu, která by jinak mohla
být věnována dalšímu zpracování skriptu. Vypnutím register_globals to
už nebylo nutné a PHP tedy reaguje v takovém případě rychleji.
- Bezpečnostní - Se zapnutými register_globals se dá poměrně snadno
útočit na webové stránky. Jestliže například víte nebo tušíte, že
skript cosi.php používá proměnnou isadmin, a na serveru jsou zapnuty
register_globals, můžete se pokusit zaútočit pomocí url
cosi.php?isadmin=1 a doufat, že podstrčená proměnná skript zmátne. S
vypnutými register_globals to fungovat nemusí.
Pozn.: To neznamená, že skripty v
prostředí, kde je zapnuto register_globals jsou všechny nebezpečné.
Spíše je to tak, že se musejí přísněji kontrolovat. Rovněž to
neznamená, že po vypnutí register_globals budou vaše skripty v bezpečí.
Jen toto konkrétní riziko je menší. Na serveru PHP je o tom celém pěkné
pojednání.
Pozn: Popsanými potížemi naštěstí
nejsou ovlivněny proměnné $_SESSION. Ty se totiž zpracovávají jinak.
Moje doporučení je: register_globals VYPNOUT a psát skripty tak, aby
fungovaly i bez něj i s ním.
variables_order
To je částečně související problém s tím prvním. Jestliže byly
zapnuty register_globals a dvě proměnné by "padly" do stejné globální
proměnné (například $_GET["id"] a $_COOKIE["id"]), která to vyhraje? To
je ovlivněnou volbou variables_order v php.ini. Ta bude nejspíš
vyjádřena pětipísmennou zkratkou ve stylu "EGPCS", kde jednotlivá
písmena znamenají:
- E - pole $_ENV
- G - pole $_GET, tedy proměnné z URL
- P - pole $_POST, tedy proměnné z formulářů
- C - pole $_COOKIE, tedy proměnné z uložených cookies
- S - pole $_SERVER, tedy informace o samotném serveru, který
soubor zpracovává
Znamená to, že při konfliktu globálních proměnných bude přiřazena do
globální proměnné hodnota z toho pole, které je v seznamu později, tedy
více vpravo.
Možná si kladete otázku: "Proč se tím zabývat - když se přece
nebudou používat globální proměnné, tak se nic nemůže stát?" Stát se
může, a to při použití pole $_REQUEST. Toto asociativní pole totiž bude
obsahovat proměnné z GET, POST i COOKIES. A pokud budou názvy
kolidovat, použije k rozřešení právě konfigurační volbu
variables_order.
Možností, jak to obejít je několik. Mezi nejznámější patří:
- Vůbec nepoužívat pole $_REQUEST a používat namísto toho pole
$_GET, $_POST a $_COOKIE.
- Nastavit si chování volby variables_order podle svých potřeb v
každém skriptu pomocí ini_set. To půjde, protože variables_order patří
zrovna mezi ty volby, které můžete individuálně nastavovat.
- Důkladně testovat data, predaná pomocí $_REQUEST, což je ostatně
vždy žádoucí.
Pozn.: Opět platí, že proměnné
$_SESSION nejsou ovlivněné pořadím předávání proměnných a tudíž nemohou
být přepsány. V praxi to znamená, že jejich použití je poměrně
bezpečné. Možná právě proto jsou tak oblíbené mezi programátory PHP
stránek.
Moje doporučení je: Důkladně testovat data. Jinak se obecně použití
pole $_REQUEST nevyhýbám protože mohou existovat situace, kdy data
mohou dorazit jak pomocí metody POST, tak pomocí metody GET. Takže to v
takovém případě zjednodušuje práci.
Příště se podíváme na zbytek konfiguračních voleb, které Vám mohou
zatopit při tvorbě webových stránek.