On and on and on and on
Wyklikanie czegoś takiego jest względnie proste i szybkie. Diabeł tkwi w szczegółach - zrobienie tego tak, żeby było wydajne, bezpieczne, nie zjadało za dużo serwera i było odporne na rejsy, to jest ten faktyczny kawałek roboty. Ble.
Jeszcze pewnie będę musiał przepisać 13kb skryptów shellowych (13kb to jest mało, tyle, że skrypty shellowe mają to do siebie, że składają się z zawiłych konstrukcji sedowo, grepowo, awkowych i jest to upierdliwe w czytaniu). Za co właściwie rzecz biorąc powinienem się zabrać już teraz, bo da mi to większe pole manewru. Hmmmm.
Bardzo upierdliwe jest tutaj uwzględnianie kwestii bezpieczeństwa. Wszyscy wiemy jak domyślnie działa apach. To teraz niech mi ktoś powie jak w związku z tym mam w bezpieczny sposób trzymać np. identyfikatory sesji? (w ogóle obecnie autoryzacja jest zrobiona na bardzo odwal się, ale ważne, że działa, poprawi się to kiedy indziej)
Jeszcze pewnie będę musiał przepisać 13kb skryptów shellowych (13kb to jest mało, tyle, że skrypty shellowe mają to do siebie, że składają się z zawiłych konstrukcji sedowo, grepowo, awkowych i jest to upierdliwe w czytaniu). Za co właściwie rzecz biorąc powinienem się zabrać już teraz, bo da mi to większe pole manewru. Hmmmm.
Bardzo upierdliwe jest tutaj uwzględnianie kwestii bezpieczeństwa. Wszyscy wiemy jak domyślnie działa apach. To teraz niech mi ktoś powie jak w związku z tym mam w bezpieczny sposób trzymać np. identyfikatory sesji? (w ogóle obecnie autoryzacja jest zrobiona na bardzo odwal się, ale ważne, że działa, poprawi się to kiedy indziej)
12 XI 2004 o 08:17:01
Rozumiem, że chodzi ci o to, żeby uchronić dane przed innymi procesami użytkownika http, tak?
No to jest kilka możliwość, chociażby:
1. użycie su-exec, albo podobnego wrappera w Apache i CGI/FastCGI
2. użycie własnego wrappera (w C, z suidem gdzieś), czy np. sudo. Ja często używam sudo w skryptach CGI itp. aplikacjach aby wykonać konkretne zadanie z wyższymi uprawnieniami.
3. uruchomienie aplikacji w serwerze aplikacji albo jako osobny serwer HTTP (Python ma do tego moduły w standardowej bibliotece), a Apache robi wtedy tylko za reverse-proxy (które może zapewniać autoryzację, SSL itp.)
Ale z bezpieczeństwem to bardziej należy uważać na cross-site-scripting (niewyeskejpowany tekst w HTMLu), code-injection, shell-injection i SQL-injection. O to szczególnie łatwo jak się nie używa procedur wyższego poziomu do pisania HTMLa, czy zapytań SQL, tylko samemu się składa używając "%", "+", print itp.
Jeśli chodzi o wydajność, to CGI plus skrypty pythona można sobie darować. mod_python nigdy nie próbowałem, ale próbowałem za to FastCGI (na modułach jonpy) i działało całkiem nieźle. Ostatnio jednak trochę miałem z tym problemów, nie wiem czy z powodu Apache 2.0, czy jonpy (które od dawna nie jest rozwijane).
BTW. na tym screenshocie to co zrobiłeś wygląda całkiem ładnie :-)
12 XI 2004 o 09:39:13
Odmawiam patrzenia na dalsze screenshoty, dopóki nie zostanie zmieniony styl w KDE.
12 XI 2004 o 10:34:58
Bartego Jakubski: Dokładnie! :D
jajcuś: mod_python jest bardzo niezły wydajnościowo (podobnież nawet szybszy od PHP)
mmazur: wydajność i bezpieczeństwo możesz rozwiązać stawiając application server; cherrypy, webware... mozna też zbudowac jakies wlasne ustrojstwo (jak ja)
12 XI 2004 o 12:17:47
Odnośnie wydajności, to chodzi nie o to, że skrypty wolne (bo tego nie będzie więcej jak 4-5kb skryptu i nie będzie jakoś superczęsto używane), tylko fakt, że ten skrypt za każdym odpaleniem (no, może nie za każdym, ale to się zobaczy) musi sobie wczytać bazę rpmów, co przy powiedzmy 300tu paczkach w test oznacza 300 plików po parę kilo, w sumie jakieś 1,5mb. A na ep09 dyski i tak przeważnie są zajechane.
Do tego dochodzi atomowe lockowanie katalogów (inaczej szybko mi się zrobi kaszanka), inne atomowe operacje i dostęp do plików, które są rw tylko dla usera ftpowego.
Najprawdopodobniej skończy się to wszystko na tym, że międzymordzie www będzie gadało po named sockecie z jakimś małym demonem w C (albo w pythonie, bez różnicy, bo to i tak będzie cały czas w pamięci, a ep09 ma gigabajt ramu :), który będzie się zajmował rzeczami takimi jak - trzymanie cały czas odpalonego poldka do przeprowadzania testów, lockowanie katalogów (jak będzie jeden jednowątkowy demon, to lockowanie siłą rzeczy będzie atomowe) i dostępem do plików.
Tylko będę musiał poszukać jakiegoś sposobu na sprawdzanie, czy program, który mi się do named socketa dossał, to jest rzeczywiście ten program, który powinien mieć do tego uprawnienia.
12 XI 2004 o 12:18:53
A - i nie wyobrażam sobie zbytnio jak może wyglądać shell injection w pythonie, chyba, że na chama próbuję zapisać do pliku to, co mi user podał (a takiej sytuacji nie będzie - operacje będą tylko na paczkach znajdujących się w test).
14 XI 2004 o 13:40:04
mmazur: na named pipes się AFAIK nie da. (w prosty sposób)
Można natomiast: DBUS (gotowa biblioteka IPC z autoryzacja; tam to działa na zasadzie chalenge i response na podstawie cookie w pliku a=,u+r - w przypadku Apache'a moze to byc malo praktyczne :P), UNIX domain sockets - maja wsparcie dla wiadomosci poza byte-streamem, przez ktore mozna przekazywac otwarte deskryptory plikow (!) i wlasnie uwierzytelniac sie jako proces i user (prawdziwosc weryfikuje jadro). W manie jest to dokladniej opisane.
Application serwer tak czy siak mozesz obadać, bo tak sie IMHO fajniej pisze, niz w stylu CGI.