waXain

Jak (szybko) sprawić by nasza strona oparta o architekturę LAMP zadziałała na lokalnym komputerze (Windows 7).  Na pierwszy rzut oka sprawa wydaje się banalna, diabeł jak zawsze tkwi w szczegółach.

1. WampServer

Pierwszym krokiem jest  instalacja pakietu WampServer – polecam ten program (jest jeszcze wiele innych typu XAMPP, Krasnal itd.) bo załatwi za nas zdecydowaną większość spraw instalacyjno-konfiguracyjnych. Po pobraniu ze strony (http://www.wampserver.com/en/) oprogramowania w najnowszej wersji (ja nie bałem się pobrać wersji beta), zainstalowaniu i uruchomieniu w zasadzie mamy już w pełni działające środowisko dostępne pod lokalnym adresem http://localhost.

Następnym krokiem jest skopiowanie zawartości naszej strony do odpowiedniego katalogu (np. C:/wamp/www/projekt. Dobrze rozplanować sobie katalogi na te dostępne i niedostępne przez www,  wyodrębnić katalog plików tymczasowych, uploadu czy wspólnych bibliotek (np. Zend Framework).

Po skopiowaniu projektu do naszej lokalizacji oczywiście warto pokusić się o jej pierwsze uruchomienie czyli wywołanie http://localhost/projekt/. Tu pewnie przywita nas niespodzianka w postaci licznych błędów

Prawdopodobnie pierwszym błędem który ukaże się naszym oczom będzie błąd ładowania wszelkich bibliotek, czyli problem separatora katalogów i redefinicji naszych ścieżek. Na Windows separator katalogów jest inny niż w systemach Linux (ukośnik w drugą stronę), stąd jeśli nie zadbaliśmy o to wcześniej teraz już będziemy musieli.  Najlepiej zdefiniować sobie gdzieś na samym początku naszej aplikacji (index.php) linijkę:

define(‘DS’, DIRECTORY_SEPARATOR);

dzięki której nie będziemy musieli wpisywać tego składającego się aż z 19 znaków słowa (co także sprawi, że nasze ścieżki będą czytelniejsze). Druga sprawa to zmiana naszych konfiguracyjnych ścieżek, zmiana wszelkich innych ustawień, w tym bazy danych. Bardzo dobrym nawykiem jest wydzielanie konfiguracji dot. serwera roboczego i produkcyjnego – wyeliminuje to problemy przy publikacjach.

2. Wirtualny host

Po tym zabiegu nasza strona powinna się już uruchomić, jednak w związku z tym iż pracujemy na lokalnym adresie gdzie nasz projekt „widziany jest” tak naprawdę jako podkatalog, czeka nas szereg nie miłych niespodzianek takich jak błędnie działające przekierowania, nie działający .htaccess, problem ze względnymi urlami itd. Aby nie zwariować w natłoku problemów, spróbujmy je po prostu ominąć

Najpierw stwórzmy adres (hosta) pod którym chcielibyśmy uruchamiać nasz projekt i dodajmy go do pliku hosts. Na Windows 7 jest to katalog: C:\WINDOWS\system32\drivers\etc\hosts . Tu dopisujemy np. linijkę (specjalnie podaję adres z kropką by maksymalnie imitował prawdziwą domenę):

127.0.0.1       projekt.home

i zapisujmy plik.

Następnie odnajdujemy plik httpd-vhosts odpowiedzialny za wirtualne hosty, w WampServer jest to katalog: C:\wamp\bin\apache\Apache2.2.21\conf\extra\ . Dokonujemy edycji ów pliku i dopisujemy w nim:

<VirtualHost *:80>
DocumentRoot „c:/wamp/www/projekt/source/www/”
ServerName projekt.home
</VirtualHost>

Restartujemy Apache. Teraz wpisując adres projekt.home uruchamiamy stronę główną naszego projektu.

3. Memcached

Jeśli w naszym projekcie korzystamy z biblioteki Memcached warto by nasz projekt także lokalnie z niej korzystał. W najnowszym WampServer odpowiedni dll (php_memcache.dll) jest już dołączony, wystarczy tylko go uruchomić (edytując php.ini lub klikając z panelu WampServer, PHP->PHP extensions). To niestety nie wszystko, trzeba także uruchomić odpowiednią usługę działającą w tle. W tym celu ze strony http://code.jellycan.com/memcached/ pobieramy wersję pod Windows (memcached-1.2.6-win32-bin.zip). Rozpakowujemy do np C:/Memcached, następnie uruchomiamy instalację wpisując z linii komend (w menu wyszukiwania/uruchamiania wystarczy wpisać cmd, następnie poleceniem cd c:/Memcached przechodzimy do odpowiedniego katalogu) polecenie:

memcached -d install

Teraz już tylko uruchamiamy usługę wpisując:

memcached -d start

4. Konfiguracja poczty

Została jeszcze konfiguracja poczty, najprostszym sposobem na wysyłkę maili w naszym projekcie jest skorzystanie z protokołu SMTP i ich wysyłka za pośrednictwem swojej poczty. Z pomocą przychodzi gmail i Zend Framework, polecam taki oto skrypt połączenia (oczywiście poszczególne jego dane powinny pochodzić z konfiguracji):

$protocol = new Zend_Mail_Protocol_Smtp(smtp.gmail.com, 587,  array(‘auth’ => ‘login’,   ‘username’ => ‘twoj_email@gmail.com’,   ‘password’ => twoje_haslo’,  ’ssl’ => ‘tls’, ‘port’ => 587 ));

$protocol->connect();

$protocol->helo($_SERVER['SERVER_NAME']);
$mailTransport = new Zend_Mail_Transport_Smtp();
$mailTransport->setConnection($protocol);

Co ważne aby wszystko zadziałało musimy mieć  włączoną bibliotekę open_ssl (i znowu albo edycja php.ini lub klikając w WampServer).

5.  Podsumowanie

Jak widać dość szybko można na naszym lokalnym komputerze uruchomić dowolną stronę nie zmieniając całej masy ustawień, przebudowując urli czy wręcz części aplikacji.

Postanowiłem podzielić się spostrzeżeniami dotyczącymi codziennej pracy/życia programisty bazując na osobistych doświadczeniach i obserwacjach ubierając je w swego rodzaju „porady”. Oto dwadzieścia punktów które najszybciej wpadły mi do głowy:

1. nie zostawiaj zbędnych fragmentów kodu, dotyczy to także nie aktualnych komentarzy – inni (w tym także  Ty!) nie będą musieli ślęczeć nad nimi i zastawiać się „co autor miał na myśli”, tracąc przy tym cenny czas,
2. stosuj jedno spójne nazewnictwo zmiennych (polecam notację węgierską) i funkcji – kod jest o wiele czytelniejszy, łatwiej „przeszukiwalny” no i przede wszystkim wymusza to porządek, który jak wiadomo jest najlepszym przyjacielem programisty (dla sprostowania – dotyczy to tylko świata programowania  – bo zaraz żona będzie chciała bym posprzątał dom ),
3. pisząc kod staraj się stosować do metody „suchego pocałunku”: DRY KISS,
4. jakikolwiek framework nie wybierzesz, pamiętaj – nie napisze on aplikacji za Ciebie,
5. zabezpieczając aplikację przed atakami (ale nie tylko) pamiętaj, że bezpieczniej (i prościej) jest ograniczać użytkownika do tego co można niż tego czego mu nie wolno (tzw. WHITELISTNING),
6. pamiętaj – każdy programista uważa, że „można napisać to lepiej”, najgorsze, że dotyczy to także (a może przede wszystkim) oceny jego własnej twórczości, wiedząc to nie zmieniaj kodu tej samej funkcji po raz 154, bo wciąż nie jest idealna…
7. to, że aplikacja działa na Twoim środowisku/serwerze nie daje żadnej gwarancji, że zadziała także na innym,
8. pliki logów nie istnieją tylko po to by w nieskończoność „rosnąć” – czasami naprawdę warto tam zerknąć,
9. myślenie boli – szczególnie jeśli myślimy nad jednym problemem od 12h, w takiej sytuacji proponuję przespać się a rano możemy stać się świadkami autentycznego cudu – WE KNOW THE ANSWER,
10. programowania obiektowego nie wymyślono tylko po to by funkcje nazywać metodami i wszystko upchać w jednej klasie
11. zastanów się czy mając bardzo ograniczony czas na realizację projektu (zbliża się deadline) to co chcesz zrobić jest na pewno tym co musisz zrobić,
12. jeśli coś przestało działać, a jeszcze parę chwil temu działało – oznacza to, że rozwiązanie Twojego problemu musi być banalnie proste…
13. natomiast, jeśli coś nagle zaczęło działać a parę chwil temu nie działało – oznacza to, że prawdopodobnie problemu nie było lub był on „urojony”,
14. dokumentuj kod – wbrew pozorom jest to oszczędność czasu,
15. SVN prawdę Ci powie, a Google zna odpowiedź,
16. wszystko dla programisty może być proste, diabeł tkwi tylko w czasie realizacji,
17. najlepszymi testerami dla Twojej aplikacji są: kot, dziecko do 3 lat i klient, za to najgorszym jej testerem jesteś Ty
18. baza danych to nie śmietnik, a jeśli nawet takim się stała, to niebawem przyjdzie Ci go posprzątać…
19. gdzieś, kiedyś (pewnie na jakimś wykładzie) usłyszałem, że dobry programista na 1000 linii kodu popełnia ok. 10 błędów – nie starajmy się tego udowadniać,
20. a tak w ogóle to najlepiej wszystko zrefaktoryzować, zoptymalizować albo napisać od nowa!

Na koniec taka, może nieco wstrząsająca ciekawostka: uznawanym za pierwszego programistę w historii jest (werble) kobieta – Ada Lovelace

Może znacie jeszcze jakieś inne „prawdy” dotyczące naszej pracy?

Jeszcze 2 lata temu gdy nasz syn mówił „mamo, tato”, dumni, pełni podziwu nie mogliśmy wyjść z zachwytu. Dziś słysząc te same słowa, jednak z częstotliwością ~1000 razy/dzień sam odpowiadam:
- „taty nie ma”,
- „idź do mamy”,
- „puszczę Ci bajkę” itp.

A miałem być przykładnym ojcem …

Oprogramowanie do zarządzania projektami o bojowej nazwie ProjectThunder połączone z siłą aplikacji desktopowej DesktopThunder zostało niedawno udostępnione Światu.  Działające w oparciu o model SaaS (Software as a Service – oprogramowanie jako usługa) może wspomóc szereg procesów organizacyjnych w małych, średnich a nawet dużych firmach.  Dla kogo jeszcze przeznaczony jest ProjectThunder?

• dla wszystkich którzy chcą kontrolować rentowności swoich projektów,
• dla wszystkich których praca przynajmniej częściowo związana jest z komputerem,
• dla firm, których pracownicy są rozproszeni po całym kraju/Świecie,
• dla wszystkich tych dla których liczy się budowanie wewnętrznej bazy wiedzy w firmie,
• dla wszystkich którzy chcą zapanować nad przepływem informacji, przydzielonymi zadaniami pracownikom i  ich rolami w projektach.

Nie będę tu marudził o czasie jego powstawania, trudnościach, zawiłościach i wszystkim innym co stało na przeszkodzie w pracach ITODO nad wypuszczeniem na rynek swojego dziecka, bo jest to pewnie dla Was mało istotne. Ważnym natomiast jest to co potrafi to cacuszko – a potrafi sporo:

• tworzenie projektów i ich etapów wraz z budżetami, kosztami (wewnętrzne, zewnętrzne),
• zarządzanie zleceniami (zaawansowane przeglądanie, dodawanie/edycja, przekierowywanie, zamrażanie/odmrażanie, kończenie, akceptacja),
• zarządzanie użytkownikami, ich uprawnieniami, grupami,
• zarządzanie bazą klientów wraz z możliwością przypisywania im przedstawicieli (mogących się logować do systemu),
• repozytorium plików (możliwość przeszukiwania źródeł plików tekstowych), repozytorium komentarzy,
• multiupload plików (także dużych) wraz z monitoringiem postępu,
• liczne mechanizmy wspierające procesy opisywania zleceń takie jak: ścieżki obiegu zleceń, tagowanie, priorytetowanie, szacunki czasowe, monitoring rezerw czasowych,
• mechanizmy wspierające procesy komunikacji:  automatyczne powiadomienia mailowe, komentarze, rozbudowany system ikonografii opisującej różne zdarzenia (zlecenie stałe, poufne, nowe, z załącznikami, z komentarzami itd.)
• rozbudowane raportowanie (raporty czasu pracy, efektywności, rentowności, bieżącej pracy),
• kreator pól pozwalający w zasadzie dowolnie rozbudowywać dane opisowe zleceń, projektów, użytkowników, klientów wsparty danymi słownikowymi i uprawnieniami,
• Dashboard, Rss Reader, wsparcie dla aplikacji Google,
• prosty, przejrzysty interfejs zawierający rozbudowane filtrowanie wybranych danych,
• wiele innych funkcjonalności…

ProjectThunder posiada także API korzystając z którego można w swoich aplikacjach (np. iGoogle) wykorzystać szereg funkcjonalności z PT. Warto też podkreślić, że aplikacja zabezpieczona jest certyfikatem SSL, tworzone są także kopie zapasowe i wdrożone liczne mechanizmy zapewniające bezpieczeństwo. Ponieważ projekt oparty jest o Zend Framework zapewnia mu to w dużej mierze stabilny rozwój oraz ułatwia utrzymanie kodu.

Ważnym elementem wspierającym ProjectThunder jest aplikacja desktopowa napisana w wieloplatformowym środowisku Adobe Air służąca do rejestracji czasu pracy (real time) oraz realizująca wiele innych funkcji, dzięki którym pracownicy nie muszą logować się do głównego systemu poprzez przeglądarkę co znacznie skraca proces obsługi zleceń (a wiadomo – czas to pieniądz .

ProjectThunder cały czas się rozwija, każda nawet drobna uwaga dot. sytemu brana jest pod uwagę przy kolejnych pracach.  Obecnie na etapie produkcyjnym trwa równolegle kilka dużych prac rozwojowych rozbudowujących aplikację o nowe funkcjonalności, które będą publikowane wraz z kolejnymi wersjami.

Na koniec zapraszam do testowania korzystając z:

• wersji demonstracyjnej: http://demo.project-thunder.pl
• wersji darmowej, lub odpłatnej (pierwsze 30 dni za darmo) którą można zarejestrować tu: http://www.project-thunder.pl/oferta/

Warto tez zajrzeć na stronę pomocy a także poczytać o funkcjach i możliwym zastosowaniu w sekcji „czym jest ProjectThunder”.

A gdybyś potrzebował(a) wezwać na pomoc ProjectThunder’a po prostu wyślij sygnał…

W skrócie – 2 powody zmiany sajtu:

1. oszczędność czasu – postawienie bloga na WordPressie oszczędza czas aktualizacji/utrzymania kodu, a co za tym idzie…
2. …mam więcej czasu na kreatywność w obszarze treści bloga (wstyd, w 2010 tylko 2 posty).

Dlaczego WordPress? Jest prosty, w nowszej wersji nawet nieźle napisany i w zupełności wystarcza do prostego blogowania . Zenda rzecz jasna nie zdradzam, po prostu nieco lenistwo wzięło górę.  Poza tym można tyle fajnych rzeczy zrobić z wykorzystaniem ZF, przy których odkrywanie koła na nowo oprogramowując „stronę bloga” mija się w mojej opinii z celem (no chyba, że ktoś oprze cały system blogerski na Zendzie…).

Na koniec dodam, że większość danych (komentarzy, postów) przerzuciłem z poprzedniej wersji bloga – stąd poza zmianą templata tak naprawdę jest to stara strona w nowej odsłonie

Dwa filmy (w obu występuje Richard Dawkins). Pierwszy to bardzo ciekawa, prawie 2 godzinna debata 4 panów (z 30 września 2007 roku) – Dawkins, Dennett, Harris, Hitchens poruszają tematy które zawarli w swoich książkach (m.in „Bóg nie jest wielki” Christophera Hitchensa czy „Bóg urojony” Richarda Dawkinsa), dzielą się spostrzeżeniami na temat reakcji opinii publicznej po ich przeczytaniu (często przekręcaniu oryginalnego przekazu).

Drugi, bardzo interesujący film, wyreżyserowany przez Richarda Dawkinsa, w którym dowodzi on, że świat byłby o wiele lepszy bez religii.

Zobacz „Czterej jeźdźcy” (12 części).

Zobacz „Źródło wszelkigo zła” (10 części).

Objawy

Po pobraniu rekordu z bazy danych (MySQL) okazało się, że kolumna przechowująca zawartość pliku (pole typu: LONGBLOB) jest zawsze skracana do długości 1MB (1048576 bajtów).

Diagnoza

W pierwszej kolejności odpowiedzi szukałem w Zend Framework, a gdy dość szybko doszedłem do wnisku że tu jej raczej nie znajdę, zszedłem piętro niżej kombinując przy zmiennych i ustawieniach serwera MySQL. Na nic to wszytko jednak się zdało, czas leciał a ja wciąż walczyłem z tym jakże dziwnym problemem. Najłatwiej by było – idąc w myśl mojej prywatnej zasady (którą uważam, że warto stosować w przypadkach tzw. „walki z czasem”):

„Zanim zaczniesz zgłębiać problem spróbuj poszukać alternatywnego a zarazem szybszego rozwiązania.”

- przechowywać pliki na dysku a nie w bazie, jednak tu nie mogłem z niej skorzystać – a szkoda.

Blogi, fora, dokumentacja MySQL nie pomagały, po około 4h poszukiwań oraz licznych testów miałem serdecznie dość. Nagle, z natłoku tych wszystkich informacji wyłoniła się niczym rosyjska łódź podwodna  taka oto wartość:

PDO::MYSQL_ATTR_MAX_BUFFER_SIZE

którą według opisu autora wystarczyło ustawić metodą (dostępną dla danego połączenia z bazą):

$connection->setAttribute(int $attribute, mixed $value)

Niestety – i to nie zadziałało. Całe szczęście z pomocą przyszła dokumentacja PHP-a, a konkretnie metody PDO::setAttribute. Na stronie pośród (raczej niewielu) komentarzy odnalazłem ROZWIĄZANIE.

Leczenie

Wystarczy do konfiguracji naszego połączenia z bazą (czyli tam gdzie mamy zdefiniowany login, hasło, hosta, nazwe bazy itd.) dodać (tu przykład dla konfiguracji trzymanej w tablicy):

'driver_options'=>array(
    PDO::MYSQL_ATTR_MAX_BUFFER_SIZE=>1024*1024*10
)

Klucz `driver_options` jest w kilku słowach opiasny w dokumentacji ZF.

No i nareszcie wszystko działa tak jak działać powinno – wartość kolumny (z zapytania SQL) z zawartością pliku powyżej 1MB jest zwracana w całości!

Ostatnio natrafiłem w internecie na interesującą wymianę zdań w temacie „jaki jest najgorszy język programowania w którym miałeś okazję pracować?”. Pomijając sens tej dyskusji (co zresztą zostało na samym jej początku wytknięte) – można nieco ciekawych informacji (o naprawdę przeróżnych językach) z niej wyciągnać no i bądź co bądź – nic tak nie działa oczyszczająco jak ponarzekanie – jak się okazuje nie tylko cecha prawdziwego Polaka

PHP poszedł na pierwszy ogień…

http://stackoverflow.com/

1. Cel

Zadanie bojowe brzmiało mniej więcej tak:

Po zalogowaniu do naszego systemu użytkownik klikając w odpowiedni link powinien zostać automatycznie (bez podawania loginu/hasła) zalogowany w systemie XYZ. Zrealizowane ma to być poprzez SSO(Single sign-on) – w tym sam proces autoryzacji ma się odbywać za pomocą cyfrowo podpisanego XML (SAML Response) w standardzie SAML 1.1, następnie zakodowanej (base64) i wysłanej POST-em pod konkretny url.

2. Czym jest SAML?

Ponieważ była to moja dziewicza wyprawa w obszary SSO poczułem się w obliczu tych wszystkich nowych informacji nieco zagubiony. W takich przypadkach w pierwszej kolejności staram się zaznajomić z teorią. Ku mojemu braku zaskoczenia ów teoria była conajmniej w 90% w jedynym „słusznym” języku – czyli angielskim.
Ponieważ co to jest SSO mniej więcej wiedziałem, pierwszy atak przypuściłem na zagadkowy skrót SAML (Security Assertion Markup Language) w wersji 1.1. Po krótkich, acz intensywnych poszukiwaniach byłem już pewny – trzeba zakotwiczyć na wyspie OASIS.

Już wiedziałem – SAML definiuje jedynie strukturę dokumentów, które transportują informacje o bezpieczeństwie, z których korzystają inne usługi sieciowe. Sam natomiast nie definiuje nowych mechanizmów czy specyfikacji w odniesieniu do procesu autoryzacji. Ot – taki specyficzny format XML

3. Generowanie wiadomości SAML.

Wodząc oczyma po kolejnych stronach jakże bogatej specyfikacji SAML, odnalazłem to co dla mnie najistotniejsze – kluczowe (z punktu widzenia samej autoryzacji) pola dla generowanej odpowiedzi (SAML Response). Były to:

• ResponseId unikalny identyfikator odpowiedzi,
• AssertionID unikalny identyfikator danej asercji, czyli pakietu informacji posiadającej jedno lub więcej oświadczeń (ang. statements) wydanych przez instytucje udostępniającą SAML, w Assertion zawarte sa podstawowe dane potrzebne do idetyfikacji – patrz dalsze myślniki,
• Issuer nasz wymyślony/unikalny identyfikator – najczęściej w postaci adresu URL strony,
• IssueInstant data/czas w UTC naszego żądania – tu dodatkowo miałem wytyczną, iż różnica czasu między żądaniem z „mojego serwea” a tego na który się logowałem mogła wynieść max 180s, później całym SAML Response był już nie ważny,
• AuthenticationInstant data/czas w UTC w którym miała miejsce autoryzacja za pomocą hasła,
• uid czyli identyfikator/login użytkownika na którego chcemy się zalogować.

Byłem gotów do skonstruowania mojego pierwszego SAML – response Wynik można zobaczyć tu: pobierz plik.

4. Podpisanie wygenerowanej wiadomośći SAML (XMLsec).

Następnym krokiem było podpisanie naszego SAML-Response odpowiednim certyfikatem (co to jest podpis XML w skrócie wytłumaczone jest tu: XML Signature). Kwestię stworzenia certyfikatu miałem ułatwioną – został on wcześniej przygotowany (dzięki Raf, Piotr ). Zainteresowanych ich tworzeniem przekierowuję na stronę http://www.openssl.org.

Wracając do meritum – podpisania naszego XML-a certyfikatem, zbyt dużego wyboru w oprogramowaniu nie ma (w szczególności darmowego…), ja skorzystałem z XMLsec Library. To co trzeba było zrobić to zbudować odpowiednią komendę:

xmlsec1 --sign --id-attr [ResponseID] --pkcs12 [plik certyfikatu] --pwd [hasło do certyfikatu] --output [docelowey plik] [źródło nie podpisanego pliku]

uruchomić (exec() w PHP) i wszystko powinno zatrybić – mamy podpisany XML!

Uwaga! Nie korzystacjcie z proponowanych na stronie autora gotowych przykładów opartych o programiki w C gotowe do skompilowania – po pierwsze mają one okrojoną funkcjonalność w stosunku do samej komendy (co już utrudnia testowanie), po drugie XML podpisany programikiem z jakiś przyczyn (pomimo, że sama operacja zakończyła się sukcesem) nie przechodził poprawnie procesu autoryzacji.

5. Próby autoryzacji.

Ostatnim krokiem w całej operacji pozostało wysłanie podpisanego XML(zakodowanego funkcją base64_encode) POSTEM. Wydawałoby się – proste jak drut, a jednak…

Zacznę od tego, że naturalnym wydawałoby się podejściem było skorzystanie z biblioteki CURL jaką oferuję nam PHP, jednakże, po zbudowaniu odpowiedniego „połączenia” (wraz ze wszystkimi odpowiednimi nagłówkami, niezbędnymi parametrami o których mówiła nam specyfikacja komunikacji z systemem do którego próbowałem się „dostać”), wielu (naprawdę wielu) próbach, wciąż otrzymywałem ten sam smutny komunikat:

„Your connection cannot be established at this time due to a communication failure (…)”.

Pozostał jeszcze plan „B” – zwykły submit formularza (oczywiście z method=”POST”), który jako przykład testu połączenia widniał w specce. Niestety i tu się zawiodłem – połączenie wciąż nie było nawiązywane, a komunikat odpowiedzi w swojej nieskończonej mądrości brzmiał tak samo: „Your connection…”.

6. Sukces

O tym jakimi środkami, po wyeliminowaniu jakiego błędu w końcu udało się nawiązać połączenie via SSO trudno jest mi jednoznacznie odpowiedzieć, gdyż złożyło się na to zbyt wiele czynników, z których większość siłą rzeczy opisałem pośrednio już w powyższych punktach. Na pewno do kluczowych zaliczyć musiałbym:

• generowanie nowego unikalnego AssertionID na każdą próbę połączenia, w przeciwnym wypadku (statycznego AssertionID) każda nie udana próba zalogowania kończyła się (czego nie byłem świadom) blokowaniem na kilkadziesiąt sekund autoryzacji (i niestety wciąż tym samym nie mówiącym nic więcej komunikatem błędnego połączenia) – co bardzo skutecznie utrudniało testowanie,
• prawidłową konstrukcją XML-a SAML response, każdy – nawet drobny błąd składni może spowodować problemy z podpisywaniem lub samą autoryzacją.
  Przykład: w części dokumentu nie podawałem URI (ponieważ podpis dotyczył całego dokumentu a nie jego fragmentu), lub później podawałem (o czym wyczytałem gdzieś w necie) – obie formy były błędne, należało podać: 

  <Reference URI="">
  

  Dopiero wtedy zadziałało – masakra nie ?

• należało skorzystać bezpośrednio z komendy „xmlsec1″ a nie programiku (w C, przygotowanego do skompilowania) oferowanego na stronie …
• WŁAŚCIWE TESTOWANIE – specjalnie użyłem tu caps-locka dla podkreślenia jak bardzo jest to istotne. Wystarczy, że przy naszych testach użyjemy jednego wydawałoby się w 100% pewnego założenia, którym będziemy się posługiwali (nie zmieniając podejścia do niego) i możemy ugrzęznąć na długie godziny, dni…tygodnie.
• skorzystanie z formularza przy wysyłaniu POSTA zamiast biblioteki CURL na którą się nieco „uparłem” – nie twierdzę, że poprzez CURL nie da się nawiązać takiego połączenia – ale takie podejście z góry generuje nam dodatkowe punkty „zapalne” – czyli miejsca gdzie możemy popełnić błędy (albo przynajmniej myśleć, że je tam popełniliśmy). Korzystając ze „zwykłego formularza” – takich miejsc jest znacznie mniej.
• założenie (na sam koniec prac), że to co robię jest dobre, tylko nie własciwie to testuje…

Oczywiście nie obyło się bez dziesiątek maili, spotkań, konferencji, no i kurwowania – aż pewnego pięknego wieczoru (ok 21:00) mogłem z radością krzyknąć „jeeeeeeeeeest!” prawie budząc dziecko :D

7. Podsumowanie

Podsumowując prace z SSO, muszę faktycznie stwierdzić, że jest to „sajg-on”, z pewnością część problemów na które napotkałem była związana z brakiem doświadczenia, z tym, że temat był dla mnie czymś zupełnie nowym.
Aczkolwiek, wydaje mi się, że jest i druga strona medalu, która ma swoje potwierdzenie w naprawdę licznych problemach opisywanych na forach/grupach dyskusyjnych związanych z SSO, SAML czy też podpisywaniem XML. Niestety jest tu zbyt wiele miejsc w których o popełnienie błędu jest bardzo łatwo – dużo trudniej takie błędy zidentyfikować.

Na koniec tego artykułu kieruje specjalne podziękowania dla całego teamu SSO z którym przeszliśmy przez to piekiełko:

• Pawła (autora tytułu tego artykułu , który bezpośrednio uczestniczył w całym procesie,
• Piotra, Rafała – za wsparcie merytoryczne, szereg dobrych rad, prace nad stworzeniem odpowiedniego certyfikatu i procesem jego podpisania,
• Michała – walkę przy przekazywaniu informacji z/do „klienta” (z którym próbowaliśmy nawiązać ów połączenie).

Postaci Rasmusa Lerdorfa myślę nikomu nie muszę przedstawiać (gdyby jednak odsyłam do Wikipedii: Rasmus Lerdorf). Spory czas temu Rasmus na swoim blogu (http://toys.lerdorf.com) napisał ciekawy artykuł o dość dziwnym tytule „The no-framework PHP MVC framework” który wywołał tam burzliwą dyskusję w efekcie której autor dodał coś na kształt sprostowania.

W wielkim skrócie – Rasmus poruszył temat uproszczenia MVC do niezbędnego mininum, podpierając się przykładem aplikacji którą napisał na potrzeby tegoż artykułu. Co więcej w sporym stopniu odciął się od zewnętrznych frameworków (nie tyle je krytykując co raczej mówiąc iż są „nadużywane”). Niektórzy z komentujących odebrali treść tego artykułu jako swego rodzaju atak na OOP a tym samym obstawienie za programowaniem proceduralnym – co oczywiście jest bzdurą.

Nie będę tu dokonywał streszczenia czy tez dogłębnej analizy tegoż artykułu – każdy zainteresowany po jego przeczytaniu sam powinien do pewnych wniosków dojść. Ja podzielę się swoimi.

Po pierwsze nie dajmy się zwariować podczas poszukiwań „idealnych rozwiązań” na potrzeby naszych aplikacji – bo takich nie ma i pewnie nigdy nie będzie. Użycie każdego z dostępnych frameworków, rozbudowanych CMS-ów / CMF-ów ma swój koszt o którym często się zapomina i o których najczęściej nikt oficjalnie nie mówi. Kosztem może być bariera wydajności, czas  nauki, małe wsparcie społeczności itd. Często wręcz okazuje się że coś co jest banalne w napisaniu w „czystym PHP” tak bardzo chcemy opakować frameworkiem, że więcej czasu poświęcamy na analize dokumetacji, for czy blogów w poszukiwaniu rozwiązań pod niego iż zapominamy o głównym celu (przy okazji tracąc czas) – napisaniu prostego kodu.

Po drugie, nie starajmy się pisać naszego kodu w OOP tylko po to by było w OOP. Dobrym na to przykładem jest opakowywanie HTML-a szeregiem klas, gdzie wygenerowanie jakiegokolwiek elementu formularza (jego właściwości, stylu itd.) leży po stronie PHP. Najgorsze są sytuacje gdzie część elementów formularza jest obiektem PHP a część zwykłym HTML-em, praca w czymś takim może być naprawdę irytująca. Tego typu sytujacje mogą mieć miejsce gdy np. dana biblioteka nie radzi sobie z bardziej rozbudowanymi formularzami lub po prostu ich stworzenie w oparciu o te biblioteki staje się zbyt czasochłonne. Oczywiście można skorzystać chociażby z takiego Zend_Form, jednakże powinno być to zawsze poparte konkretnymi korzyściami w konfrontacji z kosztami, które pamiętajmy – zawsze ponosimy.

Mniej istotne jest to co dany framework nam oferuje (większość oferuje już bardzo dużo), za to dużo bardziej to w jaki sposób to co oferuje mamy w planach wykorzystać.

Przypuszczam, że przeciętnie korzystamy z ok. 5% funkcjonalności oferowanych przez frameworki, pozostałe 95% wciąż czeka na swoją kolej. Tak naprawdę wszystko jak zawsze oscyluje wokół zdrowego rozsądku – jeśli zostanie zachowany, jesteśmy uratowani, w przeciwnym wypadku, piekło nas pochłonie

Na koniec przytoczę słowa Rasmusa, które wyjatkowo przypadły mi do gustu: „Nothing is going to build your application for you, no matter what it promises”.

artykuł Rasmusa Lerdorfa