Počítejte s různými prostředími

Nedávno jsem měl v práci možnost opravovat jednoduchý skript (jednoduchá objednávka s odesláním mailu) a pousmál jsem se, co vytvořilo ten humbuk. Stačilo přesunutí na nový server, kde měla direktiva error_reporting v PHP jinou výchozí hodnotu. Téměř celý web se ocitl v jedné chybě jen proto, že byly najednou zobrazeny chyby úrovně E_NOTICE.

Přestože většinou tyto zprávy neovlivní chod aplikaci s omezeným error reportingem, jsou známkou špatného programování, ať už z uspěchanosti, unavenosti nebo pouhé lenosti. Kód by měl být vždycky takový, že se tyto zprávy vypisovat nebudou.

Ukázkový příklad je získání proměnné z globálního pole $_GET nebo $_POST, což je velmi často využíváno při zpracování formulářů (spíše téměř vždy):
$message = $_GET['message'];
Nyní si zapněte výpis E_NOTICE a koukněte co se stane, pokud stránku načtete; PHP vás varuje, že pouíváte nedefinovaný index pole $_GET.

Správný zápis vypadá následovně. V této fázi se rovněž uplatní zkontrolovat datový typ, který očekáváte, hlavně u integerů.
$message = isset($_GET['message']) ? $_GET['message'] : '';

Kromě nedefinovaného indexu pole je druhou nejčastější chybou nedefinovaná proměnná. PHP je v tomto ohledu velmi flexibilní, až mi někdy přijde, že je to příliš. Pokud kontrolujete hodnotu proměnné, ujistěte se, jestli vůbec byla definovaná. Ještě lépe vždy proměnnou sami definujte, kontrola neinicializovaných proměnných může být s zapnutou direktivou register_globals velmi nebezpečná.

Dalším případem může být zapisovatelnost adresáře nebo souboru, se kterými vaše skripty počítájí. Místo toho, abyste byli nemale překvapeni, když skript nenajde to co potřebuje, nejdříve zkontrolujte, zda-li má dostatečná oprávnění. V takovém to výčtu mohu jít mnohem dál, pokud bych shrnul nejčastější prohřešky v tomto ohledu, tak si představím toto:

• Počítejte s všemi možnými situacemi, váše aplikace by měla běžet bez chyb nehledě na prostředí (pokud není stanoveno jinak v požadavcích, například přítomnost určitého rozšíření nebo binárky)
• Dávejte si pozor s čím pracujete, nepokládejte za samozřejmé, že je proměnná definovaná, ověřte si, že funkce dává výstup jaký očekávejte
• Vhodně a včas zachyťte výjimky a zpracujte je

Nenechte vaše skripty, aby se vám vymkly z rukou

Uživatelé na vašem webu mohou být hraví, mohou zkoušet různé parametry (např. pokud máte někde script.php?action=delete), zadávat nesmyslné hodnoty, budou se pokoušet probourat do vaši aplikaci. Nenechte je, a postavte vaši aplikaci tak, aby jste ji ovládali vy a vědeli co dělá. Musíte to ale udělat tak, aby to co nejméně zasáhlo samotného uživatele.

Na formulářích je to vidět ze všeho nejlépe, vždy si ověřte zadávané hodnoty. Využijete regulérní výrazy, kontrolu délky, někdy postačí jen kontrola datového typu. Pokud uživatel něco zadá špatně, buďte vlídní a přesměrujte ho zpátky a naveďte ho na správné řešení.

Pokud je možno více druhů zápisu nějakého pole, zkuste je zpracovat více způsoby a pokud i tehdy nebudou zadaná data dávat smysl, přesměrujte uživatele zpět a mile ho upozorněte.

Opomenutím tohoto bodu se často můžete vystavit nepříjemným věcem jako jsou XSS útoky, z nedávné doby jistě každý ví o co jde. Hlavní pravidlo tedy zní:

Předpokládejte, že uživatel může udělat cokoliv na vašem webu, dovolte mu provést jen to, co by měl!

Nepodceňte bezpečnost

Toto téma jenom zmíním ve zkratce, zaslouží si mnohem více prostoru než zde můžu poskytnout a mnoho lidí už napsalo lepší články, než bych dokázal já.

Při návrhu a psaní aplikace je potřeba dbát na bezpečnost vašich skriptů, různé zkratky jako XSS, CSRF nebo třeba SQL Injection jsou vám jistě známé.

Při tom stačí velmi málo, abyste jim zabránili. Ověřujte veškeré uživatelské proměnné a pro různé případy escapujte obsah podle potřeby.

S tímto okruhem je často spojena jedna otázka, a to jestli povolit HTML v uživatelských formulářích. V tomhle ohledu je moje stanovinsko ne, všechny způsoby filtrování značek nejsou stoprocentní a už vůbec nejsou flexibilní. Na místě je použít nějaký alternativní značkovací jazyk, jako je Texy nebo vlastní implementace známého BBCode

Závěřem

Pokud tvoříte nějakou aplikaci, piště ji s co nejlepším svědomím a snažte se dodržet všechny principy, které jsem tu sepsal. Zároveň se ale nebojte své nedokonalosti, mnoho mých skriptů by někdo napsal mnohem lépe a už mnohokrát by pomohl kritický pohled jiného člověka. Nebojte se vaši práci konzultovat s někým jiným a nechat si poradit s efektivnějšími postupy.

Tento svůj přístup jsem si v hlavě pojmenoval zero-image design, účelem je nabídnout čtenaři na oči příjemný a přehledný web i bez pracných grafických prvků.

Nápad na takovýto design jsem dostal jednou při čtení zpráv na internetu. Už nějakou dobu používám skvělý Javascriptový bookmarlet Readability, který ze stránky vytáhne text a zobrazí ho v mnohem příjemnější podobě ke čtení. Stránky by měli být pohodolně čitelné i bez takovéhoto nástroje.

Design je pořád rozpracovaný, zatím jsem se soustředil na hlavní části webu a vytvoření WordPressového templatu podle mého původní návrhu. Na mém todo seznamu je ještě pohrát si s obsahem článků, text pod perexem si zaslouží ještě nějakou péči. Rovněž chci web rozumně rozdělit obsahově a umožnit uživateli přejít tam kam chce (nebo spíš kam chci já). Trochu tu bojuju s anglickou stránkou o phpBB službách, cílová skupina mluví anglicky, ale celočeský web mi moc nenahrává.

Pro barvy jsem si vybral dvojici modré a tmavě červené, které se příjemně doplňují a na bledém pozadí zvýrazňují hlavní navigační a popisné prvky na stránce. Pozadí obsahu jsem nějak zvlášť nevybírál, projížděl jsem odstíny šedé, až jsem se dostal na hodnotu, která dobře konstrastuje s textem a příliš nesvítí na jasném monitoru.

Až na drobné změny tento design tu zůstane na mnohem delší dobu než ostatní předchozí. Z mého osobního hlediska je to asi první design, který mi úplně sedl a u kterého mám pocit, že jsem konečně trefil, to co chci. Oproti černým designům je to i pro mě vítaná změna. Doba, kdy jsem měl pocit, že tmavý návrh je to správné, už pominuli.