normanos 2.0

jestem boski, mam katanę i włoski

KohanaPHP – uwaga na .htaccess!

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").

  • 10 Comments
  • Filed under: PHP
  • CodeIgniter 1.6.0 RC

    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ę ;)

  • 1 Comment
  • Filed under: PHP
  • KohanaPHP – ruszył polski support

    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.

  • 7 Comments
  • Filed under: PHP
  • blogfrog.pl – technicznie od kuchni

    blogfrog.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.

  • 4 Comments
  • Filed under: PHP
  • Nowy BlogFrog stoi na CodeIgniterze

    blogfrog.plZ 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.

  • 3 Comments
  • Filed under: PHP