Dzisiaj taka mało przyjemna sprawa :/ Jakiś czas temu pewna osoba dostała maila, którego można by streścić słowami: “wasza aplikacja jest dziurawa, mam hasła do bazy, proponuje 150zł i wykonam odpowiednie poprawki bezpieczeństwa”. Śliska sprawa tym bardziej, że napisała to osoba udzielająca się na polskim forum Kohany, notabene także czytelnik tego bloga Nie chce tego komentować, za to proponuje lekturę wpisu Vagli. Skupmy się na samym problemie.

Problem dotyczy frameworka KohanaPHP od wersji (chyba 2.2) w której dodano internal cache w konfiguracji. Internal cache to solidny kop wydajnościowy uzyskiwany poprzez zbuforowanie na ustalony okres czasu całej konfiguracji frameworka oraz wszystkich ścieżek dostępu. Zserializowane tablice są zapisywane w formie tekstowej w katalogu /application/cache/. Nie jestem teraz w stanie stwierdzić czy złą konstrukcję .htaccess posiadała oficjalna paczka z tego czasu czy to jest kwestia indywidualnych zmian. Ważne jest abyście sprawdzili swoje poprzednie produkcje i mieli to na uwadze zestawiając nowe (jednocześnie zmieniając .htaccess standardowo dostarczany z frameworkiem). W każdym razie zestawienie inne niż kierowanie wszystkiego (z pominięciem np. css/img/js itp.) na index.php może spowodować to, że ów katalog z cache będzie swobodnie dostępny z poziomu przeglądarki, a tym samym dostęp do loginu/hasła do bazy danych stoi otworem

ps. to też jeden z powodów dla którego zawsze sugeruję przenoszenie katalogów z aplikacją i frameworkiem POZA katalog główny (tzw. webroot) dostępny na zewnątrz. W Kohanie jest to bardzo proste do uzyskania: edytujemy plik index.php zmieniając $kohana_application, $kohana_modules i $kohana_system na odpowiednie ścieżki (np. "../enginemojejstrony/application").

To chyba jedna z ostatnich notek na temat CI którego porzuciłem na rzecz  Kohany (choć  parę projektów na CI stoi więc jeszcze warto sprawdzać co jakiś czas co  u CI słychać).  Autorzy CI  ogłosili, że w SVN znajduje się już beta wersja 1.6.0, proszą o pobranie i testy przed oficjalnym wydaniem.  Zajrzałem do  changeloga i tak jak podejrzewałem wiele ciekawego tam nie znalazłem. Połowę wpisów zajmują różnego rodzaju bugfixy zgromadzone przez ostatnie kilka miesięcy, druga część to właściwie zmiany w nazewnictwie funkcji ActiveRecordu oraz  nowa  biblioteka DBForge do zarządzania bazami/tabelami.  Poza tym  jest (od dawna dostępny w SVN)  autoload  modelu,  poprawki biblioteki session (dodane tzw. flash data) oraz parę innych  drobnych, wręcz moim zdaniem mało istotnych, dodatków. Tak na prawdę w CI niemożna się spodziewać niczego nowego bez totalnego przepisania tego frameworka, a na to na razie się nie zanosi. No i dlatego mamy Kohanę

Parę dni temu ruszył polski support dla KohanaPHP framework. W obecnej chwili zostało uruchomione forum oraz strona na której są przetłumaczone teksty i poradniki z oficjalnej strony frameworka. Dodatkowo są zaczątki planety czyli agregatora wpisów z blogów na temat tego softu. Jak to z początkami for bywa – jest pusto, ale jestem przekonany, że razem z rosnącą popularnością samego frameworka i to się zmieni. Trzymam kciuki za tą inicjatywę, także dlatego, że jestem już trochę zmęczony poziomem jaki niestety oferuje nam forum.php.pl.

Krótki techniczny wywiad z Piotrem Karwatką odpowiedzialnym za kod nowej wersji blogfroga.

N: Jakie frameworki były brane pod uwagę przed przystąpieniem do pisania nowego BlogFroga i dlaczego został wybrany CodeIgniter?

PK: Po ostatecznym wyborze PHP 5 jako platformy, myślałem o kilku popularnych zrębach – m.in. Zend, Agavi, Cake PHP. Czynnikiem decydującym o wyborze CI okazała się jego szybkość i mały narzut (wygrywał wszystkie benchmarki jakie udało mi się wtedy wyszukać). CodeIgniter nie jest tak kompleksowym rozwiązaniem jak inne dostępne biblioteki – ale odbieram to jako jego zaletę. Programista otrzymuje pomoc w rozwiązaniu większości powtarzających się problemów, a jednocześnie nadal ma dużą kontrolę. Przy blogfrog.pl CI wystarczył w zupełności do implementacji frontowej strony – dopisać należało tylko kontrolki cacheujące (wykorzystałem Zend_Cache ze względu na jego dużą elastyczność) oraz dodać obsługę logowania użytkowników której CI domyślnie nie obsługuje.

N: Co zostało użyte do napisania backendu (robot) i dlaczego?

PK: Do pisania robota wykorzystałem niektóre z bibliotek wchodzących w skład Zend_Framework (tj. Zend_Cache, Zend_Feed), obsługi bazy danych PDO oraz indeksu wyszukiwania SPHINX Search. W pierwszej wersji blogfrog korzystał z parsera MagpieRSS – w nowej postawiłem na Zend – wydaje mi się dużo bardziej elastycznym rozwiązaniem oraz bardziej stabilnym – nie ma też problemu z uzyskaniem supportu. PDO jest powszechnie uważane za najszybszą bibliotekę do obsługi baz danych w PHP – po pracy nad spiderem wydaje mi się, że to prawda Zend_Cache pomaga spiderowi natomiast nie pobierać wiele razy tych samych danych, co jest szczególnie ważne przy dużej ilości feedów do sprawdzenia – wybór ze względu na elastyczność i stabilność/wsparcie rozwiązania. Co do indeksu wyszukiwania początkowo chciałem użyć Lucene w implementacji Zenda. Niestety okazało się, że jest to rozwiązanie strasznie wolne, głównie przez implementację w czystym PHP. Dlatego skorzystałem ze Sphinx Search. Silnik ten potrafi indeksować do 10MB tekstu na sekundę, a średnie wyszukiwanie trwa 0.001 s Dodatkowo autor sphinxa zapewnia niesamowity support tego rozwiązania – przy jego pomocy wraz z administratorem rozwiązaliśmy problem m.in. z NFS w ciągu… 2 godzin. Myślę, że nikt inny nie zapewniłby nam takiego wsparcia, które jest potrzebne przy serwisach o krytycznej dostępności.

N: Jak CI sprawdza się w zakresie wydajnościowym? Ile serwerów obsługuje ten projekt?

PK: CI sprawdza się bardzo dobrze, ponieważ ma mały narzut. Wąskie gardło tego rodzaju serwisów to operacje bazodanowe – które staram się cacheować. Blogfrog jest utrzymywany aktualnie na 2 serwerach połączonych w mini cluster i zostaje mu spory zapas mocy. Głównym problemem wydajnościowym nie była strona główna tylko robot – który musi zapewniać świeże notki na stronę. Robot był projektowany i pisany z myślą o minimum 10 000 blogów. Przeskanowanie 2000 blogów zajmuje aktualnie ok 1. minuty – a mam jeszcze kilka pomysłów jak to można przyspieszyć. Myślę, że najważniejsze to pamiętać o wydajności od samego początku projektowania, a potem podczas programowania i ciągle testować wybierane rozwiązania – wtedy głowa nie będzie bolała

N: Bogatszy o wiedzę nabytą podczas pisania BlogFroga możesz poradzić innym programistom na co warto zwrócić uwagę?

PK: Warto spoglądać na problem z różnych perspektyw i zadawać samemu sobie “trudne pytania” – jeśli coś nie korzysta z wielowątkowości do przyspieszenia działania – pytanie dlaczego i co stanie się gdy z tego skorzystamy; co z cachem itd.
Aby system działał optymalnie nie można przypominać sobie o wydajności na końcu – trzeba o niej pamiętać na każdym kroku i optymalizować co tylko się da (oczywiście gdy to coś już działa). Dobrze jest posługiwać się metodą “pocisków smugowych” w tworzeniu oprogramowania tego typu – pozawala łatwiej trafić w potrzeby użytkowników. Warto stawiać na proste rozwiązania które zapewniają nam to co potrzebujemy, a nie więcej

–

Piotrku dzięki za poświęcenie czasu na odpowiedź. Ktoś ma jakieś pytania? Zapraszam do komentarzy.

Z racji zboczenia zawodowego podczas przeglądania nowych stron przyglądam się nie tylko treści i grafice ale interesuje mnie także sposób budowy serwisu. Nie inaczej było i tym razem gdy na tapetę wrzuciłem nową wersję BlogFroga. I jakie było moje zdziwienie gdy po chwili zauważyłem kilka charakterystycznych dla CI elementów Kilka testów, zabawna z URLami i tak, wniosek końcowy, BlogFrog został napisany w oparciu o CodeIgnitera. Przynajmniej frontend dla użytkowników. Co jest w backendzie agregującym informacje – ciężko powiedzieć (no może oprócz tego, że “żabiasty” robot przedstawia się jako “zend_http” co by mogło sugerować użycie klasy Zend(pseudo)Frameworka). Autorzy BlogFroga całkowicie olali moje maile więc nie udało mi się dowiedzieć niczego ciekawego w tej sprawie.

Dlaczego o tym piszę? Dlatego, że takie informacje są bardzo interesujące dla innych programistów, co rusz na forach ktoś pyta o przykłady zastosowania danego frameworka w praktyce, powstają także listy takich aplikacji (serwisy oparte na: CodeIgniter, cakePHP, Prado, Symfony).

ps. Okazuje się, że jednak była odpowiedź ze strony blogfroga, a całą korespondencję nie pierwszy raz wcięło Progreso. Za parę dni więcej szczegółów w temacie BlogFroga i CI.