Przejdź do głównej zawartości

Dlaczego nie PHP - kompatibilność wsteczna (odc. 3)

Na początku marca 2012 wydano  nową wersję 5.4 języka PHP. Nowa wersja wprowadza wiele udogodnień oraz kilka nowinek do gramatyki. Na przykład możliwość używania operatora tablicowego za operatorem funkcji $obiekt->funkcja()[4]; , składni $klasa::funkcja(). Jako zupełna nowość pojawiły się długo oczekiwane cechy (ang. traits). Niestety ze względu na porzucenie części kompatybilności wstecznej niektóre skrypty/programy pisane pod 5.3 mogą przestać działać. Na taki problem napotkałem się po aktualizacji oprogramowania przez pewnego administratora, który nie informując nikogo a swoim zamiarze nagle zmienił na serwerze dedykowanym wersję PHP z gałęzi 5.3.x na 5.4.x.  

Problem dotyczył konkretnie framework'a Kohana 2.3.4. Zdaję sobie sprawę, że framework ten był pisany z myślą o PHP 5.2 jednak pod 5.3 wszystko działało jak dawniej. Po kilku godzinach ciężkich prób i walki na podstawie informacji znalezionych na forum debiana udało się wprowadzić stosowną poprawkę do kodu.

Co ciekawe - na podstawie testów (co potem znalazło potwierdzenie w wyżej wymienionym poście na forum) wynika, że funkcja ob_end_clean() działa delikatnie inaczej niż w poprzednich wersjach. Żeby było śmieszniej dokumentacja PHP nie wspomina na ten temat ani słowem. Również detal ten nie jest wymieniony na liście zmian, które powodują brak kompatybilności wstecznej tej wersji w porównaniu do poprzednich wydań. Zresztą jak widać w changelog'u zmian tych jest całkiem sporo.

Na kolejne wydania PHP czeka się całkiem długo a zmiana drugiego numerka powoduje w skrajnym przypadku zatrzymanie pracy skryptów, czego efektem jest biała strona (specyficzny przypadek dla funkcji pracującej na buforze wyjścia). Zdecydowanie bardziej intuicyjny wydaje mi się cykl wydań Python'a w którym to nawet wersja 2.7 była kompatybilna wstecz w ramach całej gałęzi 2.x. Python do tego jest w mojej ocenie językiem dużo bardziej zaawansowanym w rozwoju i dużo szybciej się rozwijającym. Mimo tego udaje się jego twórcom zachować kompatybilność wsteczną projektów.

Poza tym podobny problem dotyczy samego framework'a Kohana i jego gałęzi 3.x gdzie to przy kolejnych wydaniach twórcy aplikacji opartych na tym framework'u nie mogą aktualizować systemu ze względu na brak wstecznej zgodności.

 
Artykuł udostępniany na licencji CC-BY-SA-3.0

Komentarze

Popularne posty z tego bloga

WordPress -> SQL Injection poprzez plugin Webdorado SpiderCalendar

W zeszłym roku sprawdziłem jakość kodu oraz poprawność przetwarzania danych wejściowych przez plugin „Form Maker” przygotowany przez wydawcę Webdorado. Tym razem postanowiłem sprawdzić czy autor poprawił jakoś kodu swoich produktów. Należy tutaj nadmienić, że poza wersjami darmowymi opartymi na licencji GNU/GPLv2 oferuje on również wersję płatne z dodatkowymi szablonami. Tym razem postaram się opisać wszelkie przeszkody, które musiałem pokonać aby n apisać działającego exploita. Zacząłem zabawę tak, że program był dla mnie black-boxem, ale niestety skończyło się na przejrzeniu kodu. Zapraszam do lektury. Poniżej można zobaczyć jeden z widoków częściowych kalendarza, który domyślnie jest wywoływany z JavaScriptu jako XHR, można jednak go z powodzeniem otworzyć w przeglądarce jako widok główny: http://localhost:8888/wp/wp-admin/admin-ajax.php?action=spiderbigcalendar_month&theme_id=13&calendar=1&select=month,list,week,day,&date=2015-02&many_sp_calend...

WordPress Form Maker 1.6.5 - Stored XSS

W ostatnim czasie bawiłem się wtyczką do WordPressa o nazwie Form Maker (v1.6.5). Postanowiłem przejrzeć kod tej wtyczki i sprawdzić jego jakość oraz poziom zabezpieczenia danych przychodzących od użytkowników. Jak się okazuje poziom zabezpieczeń tego dodatku pozostawia wiele do życzenia (zresztą poziom jakości kodu źródłowego również). Wygenerowałem przy użyciu panelu zarządzania FormMaker'a formularz z jednym polem typu "select: oraz przyciski "submit" i "reset". Następnie dodałem widget do prawej kolumny bloga, efekt jest następujący:   W zasadzie pole to nie jest zabezpieczone w żaden sposób przed doklejeniem do wartości skryptu JS. Wartości te wpadają do tabelki wp_formmaker_submits do kolumny element_value. Użytkownik zarządzający (domyślnie administrator) może przeglądać w panelu WP statystyki utworzone na podstawie przesłanych przez użytkowników danych, oto przykład ( http://localhost/wordpress/wp-admin/admin.php?page=Form_maker_Submits ): ...

Przydatne skrypty w MS SQL Server dla platformy Azure

 Jak przygotować skrypt, który wyłączy "Constrainty" w MS SQL Azure:     SELECT 'ALTER TABLE [' + s.name + '].[' + o.name + '] NOCHECK CONSTRAINT ' + i.name AS a     FROM sys.foreign_keys i     INNER JOIN sys.objects o ON i.parent_object_id = o.OBJECT_ID     INNER JOIN sys.schemas s ON o.schema_id = s.schema_id Jak przygotować skrypt, który wycziści wszystkie tabele, po tym jak wyłączysz "Constrainty" w MS SQL Azure:     SELECT DISTINCT 'DELETE FROM  [' + t.name + '] ' AS a     FROM sys.tables t     WHERE t.name <> 'appusers' AND t.name <> 'flyway_schema_history'; Jak przygotować skrypt, który włączy "Constrainty" w MS SQL Azure:     SELECT 'ALTER TABLE [' + s.name + '].[' + o.name + '] CHECK CONSTRAINT ' + i.name AS a     FROM sys.foreign_keys i     INNER JOIN sys.objects o ON i.parent_object_id = o.OBJECT_ID  ...