als je zelf bouwt en test op je locale server kan je toch net zo goed de error_reporting op all zetten in je ini file, dan kan je ook niet vergeten alle fouten eruit te halen..
Ik ga zelf zoveel mogelijk situaties af, ik schakel SQL uit, probeer vanalles om een fout te krijgen, als ik die niet krijg, --> script online.
EDIT:
MAAR, het is wl goed dat je mensen erop attent maakt, want scripten gebeurt TE vaak zonder goede foutafhandeling.
Je kunt hem beter op de live omgeving ook op E_ALL laten staan met een goede error handler. Dan weet je het teminste als er iets verkeerd gaat en kun je het verhelpen.
Ja, en met een beetje pech weten je bezoekers ook dat er iets verkeerd gaat en ook wat er dan verkeerd gaat, om het vervolgens uit te buiten.
Imho kan je het best bezoekers op de hoogte stellen dat er een fout is, en meer niet. Errors en dergelijke sla je dan maar op in een bestandje of mail je naar jezelf. Een testomgeving is er immers om te testen :)
In een live-omgeving zal ik nooit E_ALL gebruiken. Waarom niet? Omdat hackers dol zijn op dit soort informatie. Hiermee leg je namelijk de structuur (al dan niet gedeeltelijk) open en bloot. Fouten schrijf je weg in een logboek en laat je nooit en te nimmer op het scherm zien. E_ALL is dus niet nodig, zelfs ongewenst.
Vorige week heb ik, met toestemming (!!!), nog een website onderuit gehaald. De programmeur zat op te scheppen over veiligheid maar bleek de input niet goed genoeg te controleren. Vervolgens werd er met de foute input gerekend en liep de hele boel in het honderd. Hij nam aan dat wanneer hij vroeg om een datum, de gebruiker ook wel een datum zou invoeren... Niet dus!
De foutmeldingen op het scherm gaven mij nog meer informatie over het systeem, waardoor ik mogelijk nog meer schade aan het kunnen richten.
Dus:
- Geef nooit enige informatie over je systeem vrij. Wees zo vaag mogelijk met gebruikersvriendelijke foutmeldingen. Zeg niet dat het wachtwoord niet goed is, meldt dat de combinatie wachtwoord/gebruikersnaam niet bekend is. Dat zegt namelijk helemaal niets.
- Controleer ALLES! En het liefst dubbel. Zet je controles in een aparte functie die je include, dan kun je deze controle functie overal in je script hergebruiken. Mocht de controle niet goed zijn, kun je hem eenvoudig updaten en is je hele website in 1x bijgewerkt/verbeterd.
- Accepteer dat je fouten maakt en dat het moeilijk is om je eigen fouten te vinden. Vraag anderen om te testen en commentaar te leveren. Ook een noob, desnoods je oma, kan waardevolle informatie verstrekken. En vergeet niet wat met deze informatie te doen.
Ik volg meestal deze informatie wel maar door bijv tijdsdruk of luiheid vergeet ik dit. Erg slechte gewoonte omdat ik denk: dat gebeurt mij toch niet. Ook al ben ik redelijk alert op dit soort zaken. Ik probeer bijv altijd met id's te werken. Hierdoor kan je de input converteren naar integer en dan pas controleren. Hierdoor is het meeste er al uit gefilterd.
Als er een foutmelding ontstaat hoef je deze niet perse aan de gebruiker te tonen. Een melding dat er iets fout is gegaan heeft een hacker helemaal niks aan. Wanneer je hem opslaat (database of e-mail) weet je teminste dat het ergens fout gaat. Ik vind het nogal dom om de error reporting uit te zetten en het dus gewoon maar te negeren als het ergens fout gaat..
Het lijkt me het best om de error reporting op E_ALL te zetten (ook live) en de foutmeldingen gewoon netjes af te handelen in een custom error handler.
@Frisbee: Tijdens het bouwen en testen gebruik je E_ALL. Uiteraard zorg je er voor dat alles wordt gecontroleerd op eventuele fouten en notices. Zodra je de boel live zet, zet je foutmeldingen ook uit. Je kunt gewoon niet het risico lopen dat er ergens nog een fout in je systeem zit waardoor relevante foutmeldingen gewoon op het scherm worden gezet.
Foutmeldingen die de error handler afvangt, komen keurig in een logboek. Maar er mag niets op het scherm komen, daarmee zet je de deur open voor hackers.
Er wordt dus helemaal niets genegeerd, maar een gebruiker mag nooit iets te zien krijgen. Dat risico is te groot.
