maliboo blog » source

JSAMF: JavaScript AMF Library

maliboo — Thu, 04 Jun 2009 15:36:49 +0000

JSAMF to javascriptowa biblioteka obsługująca istniejące serwisy AMF. Stworzona głównie na potrzeby lekkich zastosowań pisanych głównie w amfphp, PyAMF, czy AmFast. Wersja pre-alpha obsługuje tylko zdalne wywoływanie metod i odbieranie rezultatów. Docelowo chcę dodać również trwałe połączenie z serwerem do obsługi server push, pseudo-mapowanie klas i jakąś przyzwoitą obsługę błędów po stronie JS.

Po dość długich poszukiwaniach podobnego projektu okazało się, że dość podobne rozwiązanie istnieje już w Blaze DS. Jednak moim celem jest utrzymanie względnie małego rozmiaru biblioteki i jak najbardziej generycznego podejścia do tematu.

Bezpieczeństwo aplikacji FMS

maliboo — Fri, 22 Jun 2007 20:30:14 +0000

Tekst jest skierowany do osób zajmujących się poważniej FMS i rozumiejących ideę frameworka server-side Flash Media Servera 2. Jak znajdę trochę czasu to może coś więcej o tym napiszę, bo widzę, że w naszym pięknym kraju mało kto lubi dzielić się wiedzą. A ci co się już decydują sa hackowani ;) Póki co polecam ten artykuł. Jest stary jak świat, ale też jak dobre wino. Bardziej to z racji samego FMS, który w wersji drugiej nadal oparty jest na mozillowym SpiderMonkey. Adobiu! Czas na Tamarina w FMS3...

Przyszło mi rozszerzyć funkcjonalność wideoczata o moderację wypowiedzi. Moderowanie działa na zasadzie kolejkowania wiadomości w SharedObject. Moderator może się podłączyć do takiego obiektu i zarządzać listą wypowiedzi. Zawsze możemy sobie zhardkodować taki obiekt po stronie serwera i tylko ktoś posiadający wersję moderatorską czata będzie wiedział gdzie się podłączać. Ale po co cokolwiek hardkodować, jeśli można wszystko zrobić prostą metodą znaną chociażby z ciasteczek przeglądarki.

Jak wiadomo komponenty po stronie serwera mogą być dynamicznie tworzone. To dzięki temu najbardziej oporny z tfurców będzie potrafił sklecić czata. Magia dzieje się z pomocą dynamicznej instancjacji (facade.asc). Zblokować to możemy łatwo ustawiając naszą klasę do zarządzania moderowaniem na niedynamiczną. Dzięki temu nikt niepowołany nie stworzy własnej instancji komponentu moderowania po stronie serwera. Ok, mamy już bezpieczeństwo, nie rezygnując z zalet jakie daje nam koncepcja frejmłorku. Teraz wypadałoby stworzyć obiekt. I tu przechodzimy do clue. Chat posiada publiczną metodę turnOnModeration, która zwraca nazwę obiektu "moderatora". Dzięki tej nazwie możemy dokonywać magii po stronie serwera. Oczywiście wąskim gardłem jest takie zabezpieczenie metody turnOnModeration, żeby nie zwracała tej nazwy niepożądanym użyszkodnikom. Ale to temat na inny wpis.

Teraz wystarczy tylko stworzyć obiekt o losowej nazwie i zwrócić ją uprawnionemu użytkownikowi. Pomysł jest podobny do tego w jaki sposób przechowuje profile Adobe Flash Player, czy Thunderbird. Jeśli nie znam nazwy katalogu (tu: obiektu), to znając jego strukturę (tu: API) po stronie klienta, czy nawet serwera serwera nic nie wskóram. Tym sposobem możemy (chociaż nie musimy) załączyć API do moderowania w zwykłym, uniwersalnym kliencie. Teraz każdy domorosły chakier, nawet wyposażony w ostatnią wersję ASV, może nam nafiukać.

PLAIN TEXT

Actionscript:

function NameGenerator (length)
{
//Dlugosc podstawowej nazwy:
this.length = (length <= 0 || length == undefined || length> 31)? 8 : length;
var now = new Date();
this.weeks = new Date(now.getYear()+1900, now.getMonth(), now.getDate(), now.getHours());
}
//Podstawowe, dozwolone znaki w nazwie:
NameGenerator.CHARS = "ABCDEFGHIJLMNOPQRSTUVWXYZabcdefghjklmnopqrstuvwxz";
NameGenerator.prototype.getName = function ()
{
var name = "";
var i = this.length;
var rl = NameGenerator.CHARS.length;
while (i--)
name += NameGenerator.CHARS.charAt(Math.floor(Math.random()*rl));
//Zwracamy nazwe z malym timestampem pomniejszanym o losowa wartosc:
return name+((new Date()-Math.floor(Math.random()*1e4))-this.weeks);
}

NameGeneratora używam do tradycyjnego tworzenia komponentów po stronie serwera, a następnie informuję klienta-moderatora "gdzie" jest instancja. Potem zabawa wygląda tak jak przy każdym innym komponencie. Tworzymy po stronie klienta obiekt tej klasy z otrzymaną nazwą i hasanko! Zatem krzywa uczenia się dla rozumiejących temat jest prawie płaska. Oczywiście, jeśli ktoś w trakcie sesji przechwyci tę nazwę to amba. Ale jeśli komuś się to uda, to znaczy, że może przechwycić dużo więcej niemiłych rzeczy. A nazwa obiektu moderatora to będzie wtedy pikuś.

Apollo FTP update

maliboo — Thu, 10 May 2007 18:43:53 +0000

Wyczyściłem i lekko zrefaktoryzowałem kod biblioteki FTP pod Apollo, zacząłem dodawać komentarze. Wczoraj mnie naszło na przerobienie tego na coś cairngormową modłę. Niby mamy model: w postaci klienta FTP, niby mamy komendy, a wręcz ich sekwencje, nawet część odpowiedzi można by sprowadzić do value objectów... Ale jakoś nie pasuje mi upychanie w ramy tego frejmłorku.

Ale jakoś do roboty zniechęca mnie temat socketów. Ponoć nic z tym nie zrobią, zatem wysyłanie plików będzie ssało niemiłosiernie, z racji braku informacji o postępie. Oczywiście mogę i będę to fake'ował paskiem postępu (nieokreślonego), ale co to za zabawa? Obejścia w stylu wysyłania niedużego pliku i szacowania prędkości upstreamu też mnie jakoś nie zachęcają.

Idę popłakać sobie w kącie.

FlexFTP: ApolloImpl ;-)

maliboo — Wed, 25 Apr 2007 19:59:10 +0000

FlexFTP (draft)

Wiadomo, że sockety ssą. Dotknęło mnie to właśnie przy pisaniu biblioteki FTP do Apollo. Póki co traktuję to bardziej jako pilot project, niż coś do używania. Na początku pomyślałem sobie, że najłatwiej będzie wzorować się na jakiejś jawowej implementacji. Jednak wszystko co znalazłem było... Jawowe. Znaczy obsługa socketu/bufora sprowadzała się zwykle do:

PLAIN TEXT

JAVA:

while ((bytesRead = input.read(buffer)) != -1)
{
output.write(buffer, 0, bytesRead);
}
output.flush();

co w przypadku flashowego modelu zdarzeń się nie sprawdzi.

Aktualnie wygląda to tak, że mamy klienta FTPClient i komendy FTPCommand i odpowiedzi serwera FTPResponse. Klient wysyła podstawowe zdarzenia FTPEvent.CONNECTED po podłączeniu, COMMAND po wysłaniu komendy i RESPONSE po otrzymaniu odpowiedzi. Na czas wysłania komendy, czy raczej serii operacji komenda-odpowiedź klient jest blokowany, żeby nie wbić się w kolejkę akcji. Wiadomo taki jest FTP. Wszystkie akcje powinny dziedziczyć po klasie FTPInvoker. Jej interfejs zapewnia początek wywołania execute(), obsługę odpowiedzi responseReceived() i sfinalizowanie bieżącej transakcji finalize().

Nie wykluczone, czy może na pewno ostatecznie wyglądać to będzie zupełnie inaczej. Bo już na dzień dzisiejszy nie podoba mi sie sposób tworzenia pasywnego połączenia i implementacja eftepowych akcji. Aktualnie klient podłącza się do serwera, listuje katalogi i zwraca ich zawartość jako tablicę obiektów FTPFile, ściąga pliki na lokalny dysk i wysyła. Z wysyłaniem wiadomo jak jest. Postępu poznać w stanie nie jesteśmy. Bo Adobe se odpuścił na socketach... Więc jeśli ktoś ma wolne łącze, lub wgrywa duuuży plik będzie sobie musiał poczekać na FTPEvent.UPLOAD.