Pisząc Maklera stanąłem przed ciekawym problemem. Otóż aby komórka mogła połączyć się z rachunkiem maklerskim, mój program musi niejako „udawać” przeglądarkę, wysyłającą żądania. Tak więc na przykład w przypadku mBanku muszę pobrać stronę logowania, wysłać login i hasło, pobrać stronę z menu, pobrać adres strony z notowaniami, itd. Aby wiedzieć co tak naprawdę muszę wysyłać na serwer domu maklerskiego i jakich odpowiedzi się spodziewać niezbędne było „podsłuchanie” (sniffing) ruchu sieciowego do i z odpowiedniego serwera. Niestety, tutaj zaczynają się schody. Wszelkie instytucje finansowe do połączeń z klientem używają protokołu https (to „s” jest od „secure”). Protokół jest prawie tym samym co popularny http, a więc pozwala pobierać strony i wysyłać formularze, jednak zapewnia 3 dodatkowe rzeczy: spójność, uwierzytelnienie i szyfrowanie. W tym przypadku kluczowe jest trzecie słówko. Oznacza ono, że nawet jeśli postronna osoba mogłaby odczytać to, co moja karta sieciowa wysyła i odbiera, to i tak będzie to dla niej bezużyteczne, gdyż nie potrafi tego odszyfrować. Oznacza to również, że nawet i na moim własnym komputerze żaden program poza przeglądarką nie może „zajrzeć” do przesyłanych danych.

Z tego powodu odpada niestety w tym przypadku użycie standardowego narzędzia do „podsłuchiwania” ruchu sieciowego, czyli Wiresharka. Wireshark jest bardzo przyjemnym program z ładnym, kolorowym interfejsem, który potrafi wyświetlić na ekranie wszystko, co w danym momencie przelatuje przez kartę sieciową. Niestety, z powodu wyżej wspomnianej cechy protokołu https, interesujące mnie komunikaty mają nieczytelną i zaszyfrowaną postać. Chwila googlania wskazała, że teoretycznie Wireshark potrafi odszyfrować taki ruch, ale niezbędne jest do tego posiadanie prywatnego klucza serwera (a wątpię, czy mBank chętnie by się takowym podzielił). Trzeba było poszukać innej metody.

Owa inna metoda nazywa się Fiddler. Fiddler jest serwerem proxy, a więc działa jako pośrednik między przeglądarką klienta (moją) a serwerem docelowym (mBanku). Jest jednak na tyle sprytny, że gdy wykryje ruch https, nie przekazuje go „jak leci”, a dokonuje pewnej subtelnej zmiany. Otóż klientowi przedstawia się jako serwer mBanku (dzięki czemu „widzi”, co klient chce wysłać) a serwerowi mBanku jako klient (dzięki czemu umie odszyfrować również odpowiedzi). Cały ruch jest ciągle przekazywany biorącym udział stronom, a przy okazji wyświetlany w okienku Fiddlera, gdzie możemy się z nim zapoznać. Proste i genialne, wystarczy ustawić w preferencjach przeglądarki proxy o adresie 127.0.0.1 i porcie 8888 (choć Fiddler może dokonać tych zmian automatycznie). Oprócz podpatrywania ruchu jest tu też opcja pt. request builder, dzięki czemu możemy sami tworzyć żądania do serwera i odbierać odpowiedzi. Wszystkie żądania można przeszukiwać, zapisywać, eksportować i formatować (przeglądając np. listę parametrów POST lub GET).

Fiddler okazał się również przydatny w kolejnym etapie pisania Maklera, kiedy musiałem przetestować działanie stworzonej już aplikacji. Wystarczyło ustawić odpowiednie proxy (wcześniej zaznaczając opcję Allow remote computers to connect) i miałem już gotowe wygodne narzędzie do debuggowania żądań.

Niestety, nie istnieje wersja na Linuksa, dlatego trzeba było się posiłkować VirtualBoksem. Istnieją podobne narzędzia: WebScarab (napisany w Javie) i Charles (niestety płatny) – oba dostępne pod Linuksem.