Täiesti õige on veebilehte arendades lasta serveril kuvada ka kõikvõimalikke veateateid nii PHP koodi vigadest kui andmebaaside poole pöördumistest. Kui aga koduleht on valmis, siis lülita ise või lase oma arendajal need välja lülitada. Mitte ainult sellepärast et kasutajaid mitte ehmatada (kuigi ka see põhjus on oluline), vaid eelkõige ikka selleks, et veateadetes sisalduvat olulist infot saidi häkkijatele mitte anda.
Veateated on hindamatu allikas neile, kes tahavad su kodulehele sisse murda. Seal võib olla infot tuntud turvaaukude koha, koodi nõrkuste ja haavatavuste kohta samuti. Kui koduleht on arendamisel, siis arendajale endale on see kõik väga oluline info ning kui koduleht ei tööta, siis valge leht või katkine leht pole piisavalt informatiivne, et hakata programmeerimisvigu otsima. Samas hoiatavad paljud küberturbeeksperdid, et niipea, kui minnakse live´i ehk kogu maailmale nähtavaks, tuleb veateadete hulk viia minimaalseks. Muidugi võivad mõned üldisemad teated jääda, et kasutaja ei satuks segadusse, kuid täpsed pikad kirjeldused veast las jääda avalikkuse eest peitu.
Mida teha ise ja mida küsida oma arendajalt?
Kui oled otsustanud nulltolerantsi kasuks ja tahad peita kõik süsteemi genereeritavad veateated, siis võid alustada alusta PHP koodi alguses käsuga
error_reporting(0);
Paljud kodulehe tegijad aga ise koodi ei loo ning kasutavad arendajaid. Neile tuleb siis lihtsalt öelda, et live´i minnes palun peitke kõik veateated.
Tavaliselt pole nulltolerants aga väga hea lahendus. Sel juhul jäävad mõned olulised veateated saamata ka kasutajatel ja veebiadministraatoritel. Parim lahendus on lubada näidata veateateid neil ja mitte näidata teistel kodulehe külastajatel. Selleks on Wordpressi, Drupali ja teiste sisuhalduste jaoks olemas vaatsavad juhendid, mida teha.
Mida näidata ja mida mitte?
Üks levinud reegel veateadete kuvamises tavakasutajale on selline: näita teateid ainult siis, kui kasutaja ise saab midagi ette võtta, et viga kõrvaldada. Kui kodulehel on midagi katki, siis tavakasutajale ei ütle see teade suurt midagi, küll aga annab häkkeritele vihje, et midagi ei tööta ning võimalik, et seetõttu on koduleht haavatavam. Vähemalt ründaja teab, kust otsast alustada ja edasi minna.
Mõned soovitused, kuidas koostada hea veateade tavakasutajale
Mida siis ikkagi teatada ja kuidas, millest veebilehe külastajal ka kasu oleks? Siin on mõned soovitused.
- Kasuta lihtsat keelt. Väldi erialaseid ja programmeerimistermineid. Ütle, mis ei tööta ja mida kasutaja võiks teha, et see töötama hakkaks. Näiteks kui on käsil mingi ajaline uuendus või parandus, siis vabanda, et hetkel on teenus kättesaamatu ja tõenäoliselt saavad probleemid lahendatud selleks kellaajaks. Soovita mingi aja pärast tagasi tulla.
- Ole viisakas ja ära süüdista kasutajat. Kasutaja ei ole kunagi süüdi, sest arendaja ülesandeks on teha võimatuks kogemata veeb katki teha. Kui midagi siiski „kogemata“ katki tehakse, lasub süü veebitegijal. Seega igas olukorras peaks veateade jääma viisakaks ja mittesüüdistavaks. „Sa sisestasid andmed valesti“ on halb lähenemine. Selgitus, mismoodi andmeid peab siis sisestama, on õige.
- Heal veateatel on kolm osa. Need kolm osa on esiteks probleemist teatamine, teiseks põhjuste selgitamine ja kolmandaks lahenduse pakkumine. Lahenduseks võib olla ootamine, kuni asi lahendatakse, klienditeenindusega ühenduse võtmine või teistmoodi lähenemine veebilehele.
- veateade peab olema õiges kohas. Kõige tavalisem lähenemine on paigutada veateade hüpikaknana tausta kohale keset ekraani. Mõnikord on see hea lahendus (nii torkab teade kõige paremini silma), mõnikord aga, näiteks veebivormide täitmisel, halb. Siis peaks veateade olema selle koha juures, kus viga tehti. Näiteks kui jäeti mõni kohustuslik lahter täitmata, siis peaks teade olema kohe selle lahtri juures ja tekstikast ise näiteks eristuva punase joonega märgistatud.
