Tworzenie bezpiecznych aplikacji webowych na Maku? Ależ owszem, czemu nie!

Krzysztof Młynarski

3

Dodane: 14 lat temu

Tak się jakoś złożyło, że stale współpracuję z zespołem ludzi, zajmujących się tworzeniem nie tyle witryn internetowych, co całych aplikacji (najczęściej biznesowych), wykorzystujących technologię WWW do działania. Mam więc okazję podglądania ich przy pracy, słuchania o tym co ich cieszy i ułatwia im pracę, ale również o tym, co ich denerwuje, spędza sen z powiek lub wprowadza w zakłopotanie. Przez to wszystko przeplata się oczywiście moja „działka” zawodowa – czyli bezpieczeństwo. Zacznę jednak od – prawie -początku.

Jeszcze kilka lat temu, tego typu duże, interaktywne serwisy sieciowe dosłownie pisało się od podstaw (np. w słynnym i powszechnie znanym języku PHP), wspomagając się narzędziami do edycji stron lub dopasowując do swoich potrzeb gotowe pakiety klasy CMS (ang. Content Management System czyli System zarządzania treścią) – obowiązkowo, z jakimś silnikiem bazy danych „pod spodem” (najczęściej MySQL, PostgreSQL lub np. Oracle).

Problem w tym, że „ręczne pisanie” ogromnych, złożonych projektów webowych jest bardzo mało efektywne, prowadzi do powstawania szeregu zbędnych błędów i w nieskończoność wydłuża czas potrzebny na finalizację zadania. Dopasowywanie „gotowców”, czy CMS-ów również ma swoje wady. Ich wadą jest podatność na powszechnie znane błędy, które mogą być wykorzystane w relatywnie krótkim czasie od ich ujawnienia, przez włamywaczy sieciowych, zanim jeszcze administrator aplikacji zorientuje się, że nie zainstalował właśnie tej jedynej łaty. Kolejnym problemem są ograniczenia narzucane przez CMS. Jeżeli jakiś CMS narzuca mało ograniczeń (jak np. legendarna Xaraya), to zazwyczaj jest on na tyle złożony i trudny do nauczenia się, że adepci poszukujący narzędzia rezygnują z takiego rozwiązania na korzyść systemów prostszych, a co za tym idzie – o nieco mniejszych możliwościach dopasowania do potrzeb i wymagań użytkowników końcowych.

Nadszedł czas na framework. Cóż to jest? Otóż.. jest to jedno z tych słów w języku angielskim, co do którego większość z nas instynktownie czuje, co oznaczają, ale nikt nie umie tego wyrazić składnie po polsku (drugim takim słowem jest choćby popularne: enjoy! :-)).

Otóż framework (jest oficjalnie tłumaczone na język polski jako: rama projektowa, szkielet, oprawa, struktura, zrąb i wiele innych słów, w zasadzie nie oddających istoty oryginalnego terminu) to po prostu swoiste, specjalizowane środowisko do zarządzania projektami, których to projektów celem jest stworzenie aplikacji (w interesującym nas przypadku webowej) – czyli całego pakietu współpracujących ze sobą programów i statycznych zbiorów danych, dających w efekcie użyteczny produkt – np. system hotelowej rezerwacji pokoi, system finansowo-księgowy, czy np. kompleksowa obsługa szkoleń w modelu e-learningu, o portalu korporacyjnym, czy też zwykłym – internetowym – nie wspominając.

Tego typu frameworków (że będę nadal tak ładnie kaleczył ten termin) jest naprawdę wiele. Jak każde (chyba) narzędzie w informatyce, także frameworki, posiadają zajadłych fanów, którzy daliby się za nie posiekać żywcem i są gotowi bronić wyższości jednych nad drugimi na wszelakich listach dyskusyjnych, forach internetowych i czatach. Oczywiście te same frameworki posiadają swoich zaciekłych wrogów (którzy są najczęściej fanami innych frameworków). Ot, po prostu życie.

Z tego też powodu zdaję sobie sprawę, że mój tekst może nie zostać przyjęty entuzjastycznie przez wszystkich Czytelników MJ. Cóż – zaryzykuję. Zaryzykuję tym chętniej, że jakiś czas temu udało mi się trafić na framework, który daje się uruchomić na Maku „od strzału” bez konieczności żmudnej konfiguracji czy wertowania sterty dokumentacji, którego instalacja sprowadza się do rozpakowania archiwum i kliknięcia na jedną, jedyną ikonę (prawdziwie „Mac way!”), i który z definicji dba o to, aby tworzona w nim aplikacja była bezpieczna. Może nie w 100%, ale przynajmniej odporna na większość, popularnych w sieci ataków, takich jak choćby: SQL Injection, Cross-site scripting czy Insecure Direct Object Referencing. Nie wymieniłem tu wszystkich, o których pomyślano tworząc to nowe środowisko – web2py chroni nasze dzieła przed problemami, które zostały zebrane na słynnej liście zagrożeń – OWASP Top 10 (http://www.owasp.org/index.php/OWASP_Top_Ten_Project)

Dość ciekawe jest to, że dzięki wbudowaniu tzw. warstwy abstrakcji bazy danych (o tym jeszcze będę pisał dalej), która dynamicznie generuje potrzebny kod SQL – twórca aplikacji nie jest związany tym, jaki silnik bazodanowy zostanie użyty w ostatecznej wersji produkcyjnej.

Na tym jednak nie koniec… sam framework, jak i tworzone pod nim projekty są całkowicie przenośne. Co to oznacza? Otóż.. jeśli tworzymy aplikację na Maku pod Mac OS X, to jej uruchomienie np. na Linuksie, Solarisie czy… tfu.. Windows nie wymaga modyfikowania kodu (chyba, że sami postaramy się o to, używając np. specyficznych odwołań systemowych – nie polecam – choć oczywiście można).

Mam nadzieję, że podgrzałem atmosferę wystarczająco i mniej więcej w tym momencie chcielibyście się wreszcie dowiedzieć, o czym ten Młynarski tu się rozpisuje, prawda? Dobrze, nie będę kluczył dalej, chodzi o napisany całkowicie w języku Python framework o intrygującej, acz w Polsce jeszcze ciągle mało mówiącej nazwie – web2py.

Najbardziej niecierpliwi (i anglojęzyczni) Czytelnicy mogą już w tej chwili rzucić się na stronę projektu, o tu: http://web2py.com/ i od razu zacząć eksplorację narzędzia na własny rachunek. Inni mogą zacząć od polskiej witryny związanej z tym projektem: http://web2py.pl/

Niemniej ja proponuję – oczywiście – dalszą lekturę tego artykułu. Wejść na witryny związane z projektem każdy z Was zdąży, zresztą sam będę do tego zachęcał nieco dalej.

Gdybyście mieli jeszcze jakiekolwiek wątpliwości – web2py jest frameworkiem dostępnym na licencji GPL v2 – a więc jest w 100% darmowy – słowem, każdy może go pobrać, rozpakować na swoim komputerze i legalnie zacząć go używać! Tak, to jest aż tak proste.

Warto chyba zaznaczyć, że licencja GPL v2 dotyczy samego frameworka – nie oznacza ona, że tworzone w nim aplikacje muszą być rozpowszechniane na licencji GPL (w dowolnej wersji). To samo dotyczy bibliotek używanych przez web2py – wiele z nich rozpowszechnianych jest na – również darmowych – licencjach MIT i BSD i fakt, że sam web2py jest rozpowszechniany na licencji GPL v2 nie wpływa na to.

Bardzo wartościową cechą web2py jest fakt, iż zawiera on w sobie niezbędne do pracy biblioteki, zawiera swój własny (całkiem niezły nawiasem mówiąc) serwer WWW, który m.im. posiada wbudowaną obsługę SSL oraz umożliwia takie funkcje, jak choćby streaming! Cały framework, sam z siebie, dostępny jest jako… aplikacja webowa – słowem, do pracy w nim wystarczy po prostu przeglądarka WWW (Safari, Firefox, Opera.. co kto lubi).

Framework oferuje m.in. panel do zarządzania projektami, wbudowane IDE (ang. Integrated Development Environment), mechanizm warstwy abstrakcji baz danych (o tym już wspominałem…), który domyślnie wykorzystuje po prostu SQLite – możemy to rzecz jasna w każdej chwili zmienić (… a o tym jeszcze nie wspominałem), posiada wbudowany wspaniały podsystem do zarządzania wieloma wersjami językowymi tworzonej aplikacji (co jest niezwykle użyteczne w wielu projektach), udostępnia obsługę wielu modeli uwierzytelniania użytkowników, kontrolę dostępu bazującą na rolach, a gdyby tego było mało – posiada system kontroli błędów z mechanizmem wydawania tzw. biletów (ang. ticket). Ponadto istnieje wsparcie dla cache danych – zarówno w pamięci RAM jak i na dysku.

Wspominałem już, że web2py napisany jest w języku Python. Siłą rzeczy, tworzone w nim aplikacje, tak na dobrą sprawę pisane są – głównie – w Pythonie, co daje możliwość skorzystania z pełnej mocy i funkcjonalności tego obiektowego języka programowania.

Musze w tym momencie zaznaczyć, że web2py został tak pomyślany, aby wymuszał na deweloperach dobry, logiczny i spójny styl tworzenia aplikacji. Framework narzuca tzw. model MVC (ang. Model-View-Controller), czyli Model-Widok-Kontroler. Przyjęcie tego modelu umożliwia daleko idącą separację modelu danych od opisu interfejsu użytkownika oraz od logiki sterowania.

Wróćmy na sekundę do baz danych obsługiwanych przez web2py. Zasadniczo framework współpracuje z prawie wszystkim co się „rusza”, a już zapewne z tym, co się liczy na rynku, czyli z bazami: SQLite, PostgreSQL, MySQL, MSSQL, FireBird, Oracle, IBM DB2, Informix, Ingres, oraz – pewna ciekawostka – z Google App Engine. Pamiętajmy, że dzięki doskonałej warstwie abstrakcji bazy danych, aplikacja, która dziś współpracuje z MSSQL może jutro działać z PostgreSQL, MySQL lub Oracle – bez konieczności modyfikowania kodu samej aplikacji (o ile oczywiście nie wymusimy na aplikacji użycia statycznych fragmentów kodu SQL, specyficznego dla danego silnika bazy – to w web2py jest możliwe, niemniej w zdecydowanej większości przypadków można się bez tego obyć).

Dodatkową zaletą modelu współpracy z bazami danych w web2py jest fakt, iż nasza aplikacja może pracować z wieloma bazami na raz (a nie tylko z jedną bazą, stworzoną specjalnie na potrzeby danej aplikacji, której parametry są zdefiniowane w jakimś pliku konfiguracyjnym). Dzięki temu uzyskujemy jeszcze większą elastyczność.

Framework web2py posiada API dla: HTML/XML, ATOM, RSS, RTF, JSON, AJAX (jQuery), XML-RPC, CSV, REST, WIKI, Flash/AMF oraz Linked Data (RDF).

Nieco wcześniej napisałem, że web2py posiada swój własny, również napisany w Pythonie, serwer WWW. Owszem i jest on uruchamiany w momencie, w którym uruchamiamy sam framework (na Maku, klikając na ikonę o nazwie web2py.app). Chwilę po uruchomieniu frameworka pojawia nam się właśnie okienko serwera WWW, posiadające prosty dialog, składający się z trzech pól i dwóch przycisków.

W pierwszym polu (opisanym: Choose a password:) wprowadzamy hasło, którego użyjemy później logując się (już przez przeglądarkę) do panelu administratora web2py. Hasło to ustalamy za każdym razem, gdy uruchamiamy środowisko web2py.

W drugim polu mamy wyświetlony domyślny adres IP, na którym serwer web2py będzie oczekiwał na nasze połączenie. Domyślnie jest to tzw. localhost (IP = 127.0.0.1), czyli adres komputera, na którym aktualnie pracujemy. Jest to dobre rozwiązanie ze względów bezpieczeństwa – nikt poza nami nie będzie mógł połączyć się z naszym środowiskiem web2py – nawet użytkownicy tej samej sieci lokalnej. Oczywiście można w tym polu podać adres IP naszego komputera, widoczny z sieci. Wówczas pojawi się możliwość logowania do web2py z innych komputerów. Użytkownicy zewnętrzni będą mogli przeglądać zainstalowane w środowisku aplikacje, włączając w to aplikacje właśnie przez nas tworzone i testowane. Nie będą mogli zalogować się do panelu administratora web2py – nawet, jeśli poznają hasło. Tu bowiem narzucono ograniczenie: do panelu administratora umożliwiającego modyfikowanie aplikacji można się zalogować tylko z tego samego komputera, albo… poprzez bezpieczne połączenie SSL (jeśli serwer web2py nasłuchuje na adresie IP widocznym z sieci). Niemniej SSL nie jest uruchomiony domyślnie, więc przynajmniej to ogranicza dostęp do naszych narzędzi z zewnątrz, nawet jeśli nieopatrznie udostępnimy sam serwer w sieci. Procedura uruchomienia obsługi SSL opisana jest w dokumentacji web2py (o dokumentacji napiszę nieco dalej).

Trzecie pole dotyczy portu TCP, na którym będzie nasłuchiwał serwer WWW frameworka web2py. Domyślnie jest to port 8000,

Poniżej znajduje się czarne, prostokątne pole, na którym serwer będzie obrazował swoje aktualne obciążenie (w postaci przesuwającego się wykresu, rysowanego zieloną linią).

Pod tym polem znajdują się dwa przyciski o dość oczywistej treści. Zaraz po uruchomieniu serwera dostępny jest przycisk „start server”, który musimy puknąć, aby ostatecznie uruchomić serwer WWW web2py z podanymi we wcześniej omawianych polach parametrami. Zaraz po uruchomieniu serwera przycisk ten zostanie „wyszarzony”, a zaktywuje się przycisk opisany „stop server”, który służy do zatrzymania serwera web2py.

Całkowite zamknięcie środowiska roboczego web2py wraz z serwerem WWW następuje po klasycznym zamknięciu aplikacji serwerowej (dokładnie tak samo, jak zamknięcie edytora tekstu, przeglądarki WWW czy innego, typowego programu w systemie Mac OS X).

Jeśli ponownie uruchomimy web2py postępując zgodnie z podanym tu przeze mnie opisem – nasze środowisko będzie dostępne w takim stanie, w jakim je ostatnio zamknęliśmy – możliwa będzie kontynuacja ewentualnie przerwanej wcześniej pracy nad aplikacją.

Zakładam, że serwer web2py już został uruchomiony. W normalnych warunkach domyślna przeglądarka WWW startuje automatycznie i od razu otwiera nam się strona serwerowana pod adresem:

http://127.0.0.1:8000/welcome/default/index

Jeśli z jakiegoś powodu powyższe nie zadziałało, albo chcemy użyć innej przeglądarki, to należy przeglądarkę uruchomić własnoręcznie, a następnie w pasku adresu wpisać:

http://127.0.0.1:8000

i zatwierdzić ten wpis klawiszem Return (Enter).  Cały czas zakładam, że nie dokonano zmiany domyślnych ustawień serwera WWW web2py – czyli adres IP pozostał ustawiony na 127.0.0.1 oraz port na 8000. W przeciwnym wypadku, należy podać skonfigurowany przy starcie adres IP (musi to być jeden z adresów naprawdę używanych przez nasz komputer – inaczej cała operacja zakończy się fiaskiem) oraz zdefiniowany port TCP – o ile również był zmieniany.

Jeśli już piszę o serwerze WWW, to warto abym wspomniał w kilku słowach o serwerach WWW z jakimi może współpracować web2py w momencie, gdy chcemy gotową już aplikacje opublikować w sieci (wszystko jedno, czy w wewnętrznej sieci lokalnej, czy też w Internecie).

Otóż gama dostępnych opcji znowu jest dość spora. Framework web2py pracuje poprawnie z większością serwerów WWW instalowanych na serwerach w sieci. Jest to więc popularny Apache (np. z mod_proxy, mod_python lub mod_wsgi) ale również Lighthttp, Cherokee czy dowolny inny serwer, obsługujący mechanizmy CGI, FastCGI czy WSGI. Szczegółowe informacje na temat publikowania aplikacji stworzonych przy użyciu web2py w sieci są opisane w dokumentacji projektu, np. tutaj:

http://web2py.com/book/default/section/11/0

Oprócz tego, środowiskiem do udostępniania aplikacji napisanych w web2py może być GAE (ang. Google Apps Engine) i to wraz z obsługą mechanizmu OAuth.

Ciekawostką pewnego rodzaju jest fakt, że istnieje również możliwość wykorzystania serwera Microsoft IIS (osobiście nie polecam ze względów bezpieczeństwa niestety… i to nie z winy web2py, bynajmniej) przy użyciu komercyjnej aplikacji Helicon ISAP_Rewrite 3 (ale wersji pełnej, nie „Lite”). Można ją zakupić bezpośrednio u producenta (jest dostępna 45-dniowa wersja testowa, więc nie musimy kupować „kota w worku”):

http://www.helicontech.com/download-isapi_rewrite3.htm

Wracając jednak do naszej pierwszej sersji roboczej w web2py. Zakładam, że serwer web2py uruchomił się prawidłowo, przeglądarka wystartowała jak należy i naszym oczom ukazała się aplikacja „powitalna”. Dosłownie – o nazwie „Welcome”, z małym dopiskiem „dostosuj mnie!” pod tytułem (co pełni rolę zachęty do dalszej pracy).

Tak na dobrą sprawę, najciekawszym miejscem staje się w tym momencie główny panel, zawierający dwa odnośniki (w kolorze pomarańczowym pod napisem „Witaj Świecie”).

Pierwszy z nich „Kliknij aby przejść do panelu administracyjnego” daje możliwość bezpośredniego rozpoczęcia pracy z częścią administracyjno-edycyjną naszego frameworka. Drugi zaś, opisany „Kliknij aby przejść do interaktywnych przykładów” umożliwia przejście do strony, na której zamieszczono szereg użytecznych przykładów, które okażą się nieocenioną pomocą w procesie rozpoznawania nowego środowiska.

Osobiście poleciłbym wybranie drugiego z tych odnośników. W zasadzie na edycję zawsze znajdziemy czas potem. Dobrze jest zacząć od przetestowania przykładów, a najlepiej od zapoznania się z dokumentacją (ładnie „wydana” książka „online” w języku angielskim, zatytułowana „The Official web2py Book”. Jej miniaturka z rysunkiem drzewa w szacie jesiennej widnieje mniej więcej na środku strony z przykładami. Zaletą tej książki jest to, że jest stale aktualizowana online (dzięki mechanizmowi WIKI). Rzecz jasna, książka, jak i cała strona są po prostu aplikacją stworzoną w web2py!

Nie wydaje mi się, aby deweloper aplikacji webowych mógł sobie pozwolić obecnie na „komfort” zupełnej nieznajomości angielskiego. Ale jeśli przypadkiem Czytelnik należy do tego, nieco niszowego grona to… (poza jak najszybszym uzupełnieniem wiedzy) mogę zalecić lekturę polskich serwisów na temat web2py. Na przykład:

• http://web2py.pl/
• http://web2py.blip.pl/
• http://blog.pagenoare.net/2009/3/20/web2py-na-lighttpd-fcgi

W ostateczności zawsze pozostaje:

http://translate.google.pl/#en|pl|

Po zapoznaniu się z dokumentacją i przykładami, warto przejść do panelu administracyjno-edycyjnego i wreszcie zacząć przygodę z web2py nieco bardziej na serio. Można w tym celu wrócić na „stronę powitalną”, albo też od razu przejść do ekranu logowania używając adresu:

http://127.0.0.1:8000/admin/default/index

Tu należy podać „Hasło administratora:”, czyli to hasło, które sami zdefiniowaliśmy uruchamiając serwer web2py. Wiem, niekiedy zdarzy się, że nie pamiętamy tego hasła po przeglądaniu innych materiałów – np. strony z przykładami. W zasadzie nie ma problemu. Trzeba będzie po prostu zatrzymać serwer web2py, podać nowe hasło w polu „Choose a password:”, a następnie uruchomić ponownie. Otworzy się nowe okno (lub zakładka) przeglądarki z aplikacją powitalną. Stąd należy wybrać odnośnik „Kliknij aby przejść do panelu administracyjnego” i podać dopiero co zdefiniowane hasło. Uff!

Naszym oczom ukaże się główna strona panelu, zatytułowana „Zainstalowane aplikacje”. Na początku mamy trzy, preinstalowane aplikacje: „admin” (tak, to ten właśnie panel – jedyna aplikacja, która nie ma dostępnej funkcji edycji) oraz „examples” (czyli witryna z przykładami) i „welcome”, czyli aplikacja „powitalna”.

Niektórzy zaczynają pracę od modyfikowania aplikacji „welcome” lub „examples”. Ja jednak uważam, że – przynajmniej na początku poznawania web2py, warto jest zachować w stanie wyjściowym (np. po to, aby porównać swoje produkcje z tym przykładowym kodem, który ma to do siebie, że na pewno działa).

Najlepiej jest rozpocząć tworzenie własnej aplikacji. Ma to wiele zalet. Największą z nich jest to, że w chwili, gdy „stracimy kontrolę” nad swoją produkcją, zawsze będziemy mogli albo założyć kolejny projekt, albo też usunąć naszą testową aplikację i założyć ją od nowa… i tak do skutku.

Dzięki temu można śmiało eksperymentować bez obaw, że coś tam nam się zepsuje (w ostateczności, zawsze można przywrócić całe środowisko web2py poprzez proste rozpakowanie oryginalnego archiwum!).

Zacznijmy więc od wpisania jakiejś nazwy w okienko widoczne po prawej stronie panelu, opatrzone etykietą „Utwórz nową aplikację”. Ja wpisałem nazwę „pierwsza” i zatwierdziłem swój wybór klikając na przycisk „create” (czyli: utwórz).

Automatycznie utworzona, nowa aplikacja jest właściwie identyczna z aplikacją „powitalną” o nazwie „welcome”. Różni się od niej wyłącznie tytułem (w moim przypadku „pierwsza”). Zostaliśmy automatycznie wrzuceni do głównego panelu edycyjnego nowej aplikacji, którego podział odzwierciedla dokładnie wspomniany wcześniej model MVC.

Osoby zajmujące się tworzeniem witryn internetowych i aplikacji webowych powinny poczuć się w tym miejscu dość swojsko – wszak dostępne tu funkcje są w zasadzie samo opisujące się. Interfejs jest na tyle intuicyjny, że można w nim pracować nawet bez dokładnego „wertowania” dokumentacji. Przykładowe pliki utworzone automatycznie dla nowej aplikacji są również dość przejrzyste i zawierają precyzyjne komentarze.

Po dokonaniu jakichś modyfikacji (dobrym sposobem nauki jest modyfikowanie takiej domyślnej aplikacji) możemy obejrzeć skutki swoich działań. W tym celu należy wrócić do głównej witryny panelu administracyjno-edycyjnego. Aby tego dokonać, klikamy na pasku menu panelu w opcję „strona główna”. W efekcie pojawia nam się panel z listą dostępnych aplikacji.

Zakładam, że nasza testowa aplikacja nazywa się „pierwsza”. Aby zobaczyć efekt swojej pracy, wystarczy kliknąć na tym panelu w nazwę aplikacji. Jeśli nie ma rażących błędów w kodzie lub nie brakuje jakiegoś pliku wymaganego przez aplikację), naszym oczom ukazuje się witryna wygenerowana przez indeks aplikacji.

Do panelu administracyjno-edycyjnego możemy powrócić po prostu poprzez użycie przycisku nawigacyjnego w przeglądarce (oznaczającego powrót).

Podstawowe informacje na temat tworzenia własnych, najprostszych aplikacji „od zera”, można znaleźć tutaj:

http://www.web2py.com/examples/default/what

(kopia tej samej witryny dostępna jest również w naszym lokalnym środowisku)

http://127.0.0.1:8000/examples/default/what

Po kilku tygodniach przeprowadzonego przeze mnie „rozpoznania bojem” frameworka web2py uważam, że każdy, kto interesuje się tworzeniem aplikacji webowych powinien spróbować swoich sił w tym środowisku. Nawet, jeśli używa obecnie czegoś innego. Framework web2py jest niewątpliwie atrakcyjnym środowiskiem, stworzonym z myślą o bezpieczeństwie oraz o możliwie jak największym ułatwieniu nauki dostępnych narzędzi, co w efekcie skraca do minimum czas niezbędny do poznania dostępnych narzędzi.

Sam fakt, iż web2py nie wymaga jakiejkolwiek konfiguracji, posiadania serwera osobnego serwera WWW i serwera bazy danych powoduje, że pracę w nim można rozpocząć dosłownie w kilka minut, na dowolnym komputerze z systemem Mac OS X (10.4 lub nowszym), Windows, Linux czy UNIX.

Aplikacje tworzone w web2py na Mac OS X są domyślnie w 100% przenośne na dowolną inną platformę. Słowem – tę samą aplikację możemy tworzyć np. jakiś czas na Maku, potem jakiś czas na Linuksie bądź Windows i znowu na Maku – bez konieczności dokonywania zmian, rekonfiguracji itd.

Ważną zaletą web2py jest jego kompatybilność kolejnych wersji. Dokonując aktualizację do nowszej wersji web2py wiemy, że nasze aplikacje będą z nią działać – pomimo, iż były tworzone w wersji starszej.

Mam nadzieję, że przynajmniej część z Was zainteresowałem tym frameworkiem i okaże się on dla Was ciekawym i użytecznym narzędziem – tak, jak okazał się nim dla mnie.

A teraz zapraszam na stronę:

http://www.web2py.com/examples/default/download

i do dzieła!

Krzysztof Młynarski