ukrywanie błędów PHP dla adminów… i developerów
Standardowo pisane skrypty PHP nie zaczynają linii kodu od @ wyłaczającej drukowanie błędów w kodzie HTML. Standardowo za to serwery PHP konfigurowane są tak, żeby takie błędy w kodzie strony pokazywać. Standardowo aplikacje PHP, nawet te dokonujące zmian konfiguracyjnych w .htaccess też nie dopisują odpowiednich dyrektyw mogących to zmienić. Ba! Nie dają nawet takiej opcji, (sidenote: trzeba by zgłosić taki feature request).
Czym właściwie coś takiego grozi? Cóż - to już zależy od tego, co jest zaimplementowane w kodzie. W wypadku wordpressa wypluwa zapytania SQL, (swoją drogą - całe mnóstwo, ale o tym już pisałem w jednej z poprzednich notek, tag wordpress, sql) a także np. ścieżkę, gdzie znajdują się fizycznie w danej konfiguracji serwera niektóre pliki. Źle napisana aplikacja/plugin potrafi zwrócić dużo więcej informacji, (np zapytanie mające w sobie hasło albo inne wrażliwe informacje.
Jak sobie z tym radzić? W zasadzie warte uwagi jest w tym zakresie kilka dyrektyw. W php.ini możemy umieścić:
log_errors = on
error_log = log/my_php_errors.log
Pierwsza linia wyłączy wyświetlanie błędów. Ponieważ jednak nawet na maszynie produkcyjnej warto zauwazyć, czy coś się nie psuje, druga linia włącza logowanie na zewnątrz, zaś trzecia dokładnie określa cel, do którego zdarzenia mają się logować. Celem nie musi być plik - może to być syslog, czyli albo log systemowy Linuxa albo Event Log ![]()
Dla administratorów, którzy nie mogą niestety wyłączyć tej funkcjonalności na poziomie całego serwisu, proponuję w konfiguracji Virtual Host albo w .htaccess następujące zapisy:
php_flag log_errors on
php_value error_log log/my_php_errors.log
Oczywiście innym problemem jest wyświetlanie użytkownikowi informacji o tym, że błąd nastapił, co zazwyczaj, szczególnie jesli kaleczy to funkcjonalność serwisu w sposób znaczący. Powinny być to jednak przypadki zdefiniowane, (nawet niezdefiniowane w wypadku dodania handlera ogólnego uznaję za zdefiniowane) i obsłużone komunikatem błędu czytelnym dla użytkownika a bezpiecznym dla systemu. Ten temat w całosci jednak pozostawię developerom
Do poczytania: Error Handling and Logging Functions.
Comment from risstof
Time: 17/07/06, 19:25
Bardzo fajny artykul dlugo tego szukalem. Szczegolnie podoba mi sie log z bledami.