Najładniejsze szablony nie sprzedadzą się same, kiedy klient oczekuje, że serwis będzie robił coś więcej niż prezentacja statycznej treści. Tutaj potrzebne są języki server-side, a ja akurat specjalizuję się w PHP (co nie przeszkadza mi swobodnie poruszać się w Perlu, Pythonie i w miarę sprawnie radzić sobie z kodem Ruby — nie uważam PHP za najlepszy język i o jego wadach już kiedyś pisałem).
Konfiguracja środowiska
Na potrzeby rozwoju aplikacji mamy uruchomione własne mini-środowisko, klasyczny LAMP, z PHP5 na pokładzie. Większość konfiguracji to wierna kopia ustawień maszyn produkcyjnych, na których aplikacje są wdrażane, jest jednak kilka kwestii technicznych, o których warto wspomnieć.
error_reporting- zawsze ustawiony na najwyższy poziom, z
E_STRICTwłącznie, PHP wybacza za dużo, żeby pozwolić sobie na zignorowanie choćby jednego notice register_globals- bezwzględnie wyłączony, poleganie na tym mechanizmie to proszenie się o kłopoty (wystarczy powiedzieć, że spory odsetek ataków na serwisy wynika właśnie ze stosowania automatycznie rejestrowanych zmiennych), a zastosowanie w ten sposób uzyskanych zmiennych w środowisku obiektowym — nikłe
magic_quotes_gpc- cóż — chciałoby się napisać, że to zło, ale jeszcze przez jakiś czas aplikacja, przy której pracujemy, będzie wymagać tego ustawienia — brak wsparcia dla preparowanych zapytań w pierwszych wersjach sprawił, że teraz jeszcze trudniej byłoby je zaimplementować — w najbliższym czasie do projektu dołączy kod, który usuwa automatyczne cytowanie, jeśli jest aktywne, a następnie cytuje ponownie zawartość tablic
$_GET,$_POST,$_REQUESTi$_COOKIE
Biblioteki
- PEAR
- niewątpliwie, najobszerniejsza biblioteka rozszerzeń językowych dla PHP, paczki Mail i Mail_Mime stanowią podstawową część większości z naszych aplikacji
- CakePHP
- szkielet do szybkiego prototypowania i wdrażania aplikacji o średnim i małym poziomie skomplikowania — pozwala minimalnym nakładem kodu uzyskać maksimum funkcjonalności, a przy tym posiada wygodne narzędzia do testowania aplikacji
- Smarty
- jeden z najwygodniejszych i najłatwiej rozszerzalnych silników szablonowych dla PHP, zbudowany na bazie wtyczek i pozwalający na wykonywanie praktycznie dowolnych operacji na przekazanych przez silnik danych — jednocześnie chroni wnętrze aplikacji przed złośliwymi zmianami w szablonach i optymalizuje czas wykonania kodu przez utrzymywanie cache szablonów w postaci skompilowanej do kodu PHP
- class.jabber.php
- od dłuższego czasu nierozwijany, ale wciąż jeden z najbardziej wszechstronnych interfejs do sieci Jabber, używany przeze mnie do wysyłania automatycznych powiadomień z poziomu serwisów
- Magpie RSS
- bardzo wygodna klasa do parsowania wszelakiej maści kanałów informacyjnych, wbrew nazwie, świetnie sobie radzi z dokumentami Atom
Bezpieczeństwo kodu
- ionCube PHP Encoder
- jeden z wiodących na rynku pakietów do nieodwracalnego szyfrowania kodu, tańszy od konkurencyjnego rozwiązania Zend Guard i oferujący praktycznie identyczną funkcjonalność, a przy tym powszechnie dostępny na polskich serwerach
- eAccelerator
- darmowy, ale znacznie uboższy w funkcje kuzyn komercyjnych narzędzi do zabezpieczania kodu, wywodzący się z bazy kodowej popularnego przodka — Turck mmCache, jedyne dostępne narzędzie w przypadku serwerów home.pl
A czego wy używacie w codziennej pracy? O edytorach postaram się podyskutować następnym razem, więc póki co, zostańmy przy języku.
Technorati Tags: php, encoder, accelerator, template, smarty, jabber, pear, cakephp, rss, tools
hmm… eAccelerator, lighttpd, smarty, adodb nic wiecej do szczescia nie jest potrzebne… no i odrobina cierpliwosci ;)
ja staram sie nigdy nie korzystać z PEAR’a, AdoDB jest świetne ale też nie korzystam :),
jabber class i magic RSS a owszem, ale aplikacje się na nich nie opierają wiec można ich uzywać… nigdy jeszcze nie próbowałem czy mój serwer ma cos takiego jak te accleleratory … jak to sprawdzić ?
Z tego co mi wiadomo to w PHP6 ma już nie być ani register_globas ani magic_quotes … dobrze bo od zawsze były one powodem kłopotów.
Do maili: phpmailer
Szablony: FastTemplates (jako zaszłość), jak coś nowego to OPT
Jeśli coś z jabberem związanego, to też class.jabber.php.
Do DB kiedys natywnych funkcji (tylko mysql, nigdy prawie nie używałem innej bazy), teraz PDO.
W sumie tyle. Resztę mam własną, albo piszę z palca czasem. Przymierzam się tez do Cake, żeby poznać co nieco, ale ostatnio nie mam czasu żeby go na to poświęcić :/
w samych smarty pluginy: smartyvalidate, smartypaginate, thumb (http://www.cerdmann.com/thumb/)
często jeśli wystarczają to odpowiedniki kombajnów: smarty lite i adodb lite
Ja ze względów bezpieczeństwa to bym jeszcze fopen wyłączył. No wszystkie niepotrzebne moduły.
carstein:
A fopen blokować w jakim celu? Smarty blokują includowanie zewnętrznych plików, a bez tego ciężko choćby RSS parsować.
Jak chodzi o ułatwianie sobie życia i przede wszystkim oszczędność czasu przy debugowaniu to przede wszystkim jakaś prosta klasa wyciągająca informacje o stosie wywołań funkcji w przypadku pojawienia się błędu.
magic_quotes_gpc - fakt, porażka. A jeszcze ciekawiej jest jak ktoś włączy magic_quotes_sybase. A tak na boku, jeśli już zacytujesz $_REQUEST to pozostałych trzech chyba już nie trzeba. :)
Nowych rzeczy to nie dorzucę bo generalnie używam tego co już wymieniłeś.
@kwdowicz: A czemu starasz się nie korzystać z PEAR’a? Moim zdaniem jeden z lepszych zbiorów bibliotek. Fakt, czasem coś tam trzeba poprawić w nich i posprawdzać pod względem bezpieczeństwa ale mimo wszystko wydaje mi się, że nie ma sensu z palca pisać tego co już ktoś napisał.
@Draakhan: jak dla mnie strasznie kobylaste, chcesz skorzystać z jednej czy dwóch klass musisz mieć zainstalowane 12 różnych. Jak już naprawdę nie ma co pisać z palca to wole poszukać coś sprytniejszego, a i tak od jakiegoś czasu wszytsko buduje na cakePHP i najwyżej dołącze kilka drobnych vendorów typu FCK, smarty (ewentualnie jak sam nie robie HTMLA, bo jak robie to ), jabber.class czy magic rss.
sory… (…) bo jak robię to używam zwykłego php, bez szablonów (…)
Do debugowania to polecam narzędzia typu DBG.
W naszych aplikacjach każdy błąd i ostrzeżenie są wyłapywane przez klasę obsługi i jeśli aktywny jest tryb rozwojowy, to wyrzucany jest cały backtrace. Podobnie z klasą do obsługi bazy (klasa dziedzicząca po mysqli).
Jak mieliśmy się okazję przekonać że DBG ma sens tylko na serwerze deweloperskim, na produkcji odradzam.
szablony: OPT, przy malutenkich sajtach albo odchudzony OPT albo (kiedys) smarty-lite.
obsluga baz: PDO z nakładką OPD
Teraz Polska! :D
Patrys:
Tu się właśnie kłania cała pierdołowatość języka PHP: brak rozgraniczenia pomiędzy odczytem z zewnętrnzych serwerów, a wnętrza serwera.
Fopen blokuje się po to, aby uniemożliwośc wykonywanie ataków XSS. Zdaje sobie sprawę, że często nie można tego zrealizować. Niemniej jednak, czasami warto to choćby rozważyć.
Konfiguracja tak jak wyżej.. jeszcze dorzucę, że określam dostęp wszystkich metod klasy (public, protected czy private) jak i kiedy tylko możliwe określam typ parametrów funkcji.. to też dosyć istotne w wyłapywaniu błędów.
Do debugowania Xdebug, efektywniejsze mi się wydaje analizowanie przejścia kodu niż klikanie F12 i zgadywanie gdzie coś skręcilo nie tam gdzie trzeba. Do przetrawiania trace’a napisałem dodatkowy skrypt, który w czytelniejszy wypluwa na stronę przejście przez algorytm.
Jeśli chodzi o szablony, wyjściowe dokumenty to tylko XML’e w moim przypadku, napisałem klasy, poprzez które buduję czy też wypluwam drzewo DOM. Kiedy pracuję nad kodem drzewo faktycznie jest budowane poprzez rozszerzenie DOM i automatycznie walidowane jeśli mam takie życzenie. Natomiast kiedy wystawiam stronę na zewnątrz wszystko od razu jest przekierowywane na wywołania ‘echo’ by nie wykonywać nie potrzebnych operacji. Parę miesięcy zacząłem w ten sposób pracować i co raz bardziej sobie cenię to podejście.
Odnosnie magic_quotes, to lepiej chyba , ze jest on wlaczony, niz nie.
Na pewno wielu aplikacjom to pomoglo, przed tzw ,,popsuciem”.
Fakt, ze czasem trzeba stripowac te slashe, ale koniec koncem i tak stosuje sie rozne funkcje do cytowania jak np mysql_real_escape etc.
Czy moze sie myle?
-> h
Myślę, że zdecydowanie powinno się mieć wyłączone magic_quotes. Jak masz dobrze zaprojektowaną aplikacje, rozbitą na moduły, moduł który dodaje dane do wprowadzenia bazy powinien dostać dane w takiej formie w jakiej powinny one się znaleźć się w bazie. To on powinien odpowiadać za przygotowanie zapytania i jego wykonanie, myślę, że powinien on być niezależny od źródła pochodzenia danych. Być może, kiedyś będziesz chciał wstawiać dane na przykład z pliku XML.. itd itd.
Znaczy tak, rozumiem, tez tak uwazam, myslalem tylko, wzgledy przeciw maja jakies glebsze podloze
-> h
Gdzieś kiedyś czytałem, że ciągi znaków, do wprowadzania do bazy MySQL należy cytować tylko za pomocą mysql_real_escape(), bo tylko ta funkcja robi to prawidłowo.. tak więc byłby to kolejny argument przeciw magic_quoutes, które po prostu aplikują addslashes()
Nie mniej nie wiem do końca jaka dokładnie jest różnica między między real_escape a addslashes, prawdopodobnie chodzi o inne zastrzeżone znaki w mysql, które mogą okazać się kłopotliwe w przypadku jakiś specyficznych ciągów znaków.
class.jabber.php został podjęty i jest rozwijany
magic_quotes_gpc - masakra, najlepiej off. Zawsze lepiej przelecieć tablice “ręcznie” a do sql’a używać jakiejś natywnej funckji dla db (np. mysql_real_escape_string).
error_reporting - preferuje ustawiać w .htaccess : php_value error_reporting 4095 (bo często przy przenoszeniu aplikacji z warsztatu na inny serwer nie mogę korzystać z php.ini - a .htaccess coraz częściej jest dostępny)
Michał:
Co do cytowania danych dla SQL — na ogół wystarczy zwykłe cytowanie cudzysłowów i apostrofów.
Ustawianie error_reporting z poziomu .htaccess to paskudna metoda. To są predefiniowane stałe i nikt nie da ci gwarancji (i nie powinien), że wartości liczbowe będą identyczne w kolejnych wersjach PHP. Od tego jest funkcja ini_set(…).
Na ogół tak… ale w pewnych znanych i być może w takich co dopiero wyjdą w praniu nie da rady, a funkcje o których mówiłem napewno będą nieustannie uaktualniane.
Więc wolę pozostać przy pewnej metodzie.
ini_set() - tak, w sumie zapomniałem o tym… ale z tego powodu, że kiedyś odrzuciłem to ze względu na szybkość (mimo, że w praktyce jeszcze nie tworzyłem oprogramowania pod silnie obciążony sprzęt, to jednak chęć optymalizacyjna zawsze jakaś jest). Rzeczywiście, dobre to rozwiązanie (oczywiście dla nie wszystkich projektów - choć zdecydowanej większości owszem).
A co do wartości liczbowych… tak, gwarancji nikt nie daje. Jednak biorąc pod uwagę historię stanie się to raczej na długi czas standardem.
Ewentualny upgrade aplikacji w związku z taką zmianą nie powinien stanowić problemu… a jakiej dokładnie Ty metody używasz? E_ALL | E_STRICT? Z tego co kiedyś gdzieś czytałem, to wywołane to z poziomu php przez error_reporting() nie pokazuje jednak wszystkich błędów.
Michał:
Nie pokazuje błędów na poziomie parsera/leksera PHP, ale błędy składniowe raczej cię chyba nie interesują (wyłapują się zawsze same i są nie do pominięcia).