Witam. Mam problem z zalogowaniem się do Banku za pomocą curla. Curl nie jest mi obcy jakkolwiek nigdy jeszcze nie używałem go z SSL. I teraz pojawia się problem... Zaraz po wejściu na stronę główną dostaje długie ciasteczko, potem odrazu zostaje przekierowywany na następną stronę, gdzie zostaje do adresu za pomocą GET'a przypięty rid=....., który jak mniemam jest generowany poprzez moje ciasteczko, które wcześniej dostałem. Tutaj jest miejsce na login, który mogę wpisać. I teraz jak się za to zabrać? Wszystkie serwisy oparte na cookies, nie są jakimś nadzwyczajnym problemem....wejscie na strone, ciasteczko, potem znowu wejscie, ciasteczko, dane post i juz sie ma to co sie chce. Tu natomiast mam problem. Czy jest ktoś w stanie mi pomóc?
Poniżej funkcja realizująca zapytanie cookie, post.

[PHP] pobierz, plaintext 
<?php
public function conn_post_cookie($str_http, $in_timeout, $bool_followlocation, $bool_rtransfer, $str_array_args){
        
        $str = $this->post_fields($str_array_args);
        
        $curl = curl_init();
        
        curl_setopt($curl, CURLOPT_URL, $str_http);
        curl_setopt($curl, CURLOPT_TIMEOUT, $in_timeout);
        curl_setopt($curl, CURLOPT_FOLLOWLOCATION, $bool_followlocation);
        curl_setopt($curl, CURLOPT_RETURNTRANSFER, $bool_rtransfer);    //if '1' everything goes to var, '0' only success - 1 or failed - 0
        curl_setopt($curl, CURLOPT_USERAGENT, 'Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3');
            $headers = array('Accept-Language: pl,en-us;q=0.7,en;q=0.3',
                            'Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7');
        curl_setopt($curl, CURLOPT_HTTPHEADER, $headers);
        //curl_setopt($curl, CURLOPT_HEADER, 1);    //server headers
        
        curl_setopt($curl, CURLOPT_POST, 1);//post method
        curl_setopt($curl, CURLOPT_POSTFIELDS, $str);        
 
        curl_setopt($curl, CURLOPT_COOKIEJAR, 'cookies.txt');
        curl_setopt($curl, CURLOPT_COOKIEFILE, 'cookies.txt'); 
        
        //curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, FALSE);
        //curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 2);
    
        ob_start();
        $source=curl_exec($curl);
        ob_end_clean();    
        curl_close($curl);
 
        if (!$source)
            throw new Exception('Connection failed or website does not exist!');
        else{
            return $source;
        }
    }
?>
[PHP] pobierz, plaintext 

Jakby ktoś mógł mi jeszcze rozjaśnić funkcje (ale dokładnie)
//curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, FALSE);
//curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 2);
to byłbym wdzięczny....

Poniżej przedstawię jeszcze jak sie ma sprawa:
Wpisuje w przeglądarce:
www.ebank.pl
dostaje ciasteczko
Następuje przekierowanie:
https://www.ebank.pl/jbank-web/jbank/unlogged/loginUser.do?rid=0.9849224543367993<-identyfikator przy adresie
pojawia sie ekran z logowaniem...
gdy wpiszę login to wysyła dane POST, gdzie jest moj login i sequenceId=...........(nie wiem skąd to bierze) oraz te długie cookies. Nie ogarniam tego, dlatego pytam sie czy w curlu cały ten mechanizm jest w jakiś sposób zautomatyzowany? I czy te dwie powyższe funkcje powinny załatwić sprawę...?

po pierwsze bez tych 2 zakomentowanych linijek nie uda sie - one wlasnie odpowiadaja za laczenie sie w trybie ssl czyli https

co do sequenceId
domyslam sie ze jest to kod generowany dynamicznie i musisz go wyciagnac ze strony logowania. w momencie kiedy pobierasz ta strone do zalogowania sie musisz za pomoca preg_match wycianac ten ciag znakow i go tez oczywiscie wyslac post'em

Rzeczywiście....zaskoczyło mnie to... sequenceId i caly adres gdzie się je postuje jest ukryty w hidden inpucie . Teraz tylko gnębi mnie problem.
Błąd sesji.
Błedne parametry sesji. Twoja sesja została zakończona


Przerywa mi gdzieś sesje

ok, zgaduje po raz drugi, bo raz juz trafilem.

sprawdz czy ciastko wogole Ci sie zapisuje na dysku i pamietaj zeby przy kazdym uzyciu curl z sll wysylac to ciastko.
sprawdz takze czy w post'cie nie ma jeszcze zadnych dodatkowych pol.

no i przyjaciel hakera - Live HTTP headers - wtyczka do ff

Hm... sprawdziłem wszystko i teraz jestem o krok dalej.... Tam było jeszcze jedno żądanie które Getem wysyłało pod troche inny adres,
https://www.ebank.pl/jbank-web/jbank/userImage.gif;jsessionid=14B50cxxc6C538B1675BEE8396ED7A8D9.01?login=user i doklejało tego login=user. Teraz z kolei jest cos takiego
Serwis chwilowo niedostępny.

Jak usuwam to ostatnie żądanie to wraca z problemem sesji.....To ostatnie żądanie dotyczy pewnie obrazka, który jest związany z użytkownikiem i wyświetla się przy logowaniu

Przejrzałem wszystkie headery i zapytania jakie sie pojawiły w firebugu i LiveHTTP i nadal wywala ten sam błąd. Nie wiem co tu jest jeszcze do zrobienia, żeby działało. Musi być coś, co nie przepuszcza nadal. Może blokada czasowa, odstępy pomiędzy wejściem na stronę a kliknięciem...

Doszedłem wreszcie... A mianowicie dodałem Refererów w żądaniach tak jak jest w przeglądarce i przeszło dalej

Uważaj bo pomyślą, że chcesz się włamać i wyślą Ci gliny do domu..... Komuś się już zdarzyło :-)

Ale niby czemu mieliby wysyłać gliny? Przecież żadnych forcowych działań nie robię. Nie próbuje obejść niczego, tylko chce się połączyć ze "swoim" kontem bankowym w celu przyspieszenia dostępu do informacji. Samo łączenie przez curla oraz sam curl nie jest jakimś programem łamiącym zabezpieczenia, czy też jakimś cudownym środkiem 'hakierskim'. Imituje on jednymi słowy przeglądarkę, więc jakby to powiedzieć...sprawia wejście na strone nawet trudniejszym niż przez nią. A łączenie się z różnymi serwisami w celu przyszpieszonego zaczerpnięcia konkretnych informacji nie jest niczym karalnym. Przecież ludzie łączą się z allegro, nasza-klasa, czy innymi sklepami aby dostać infromacje które tylko ich interesują. Nie mowię tu o botach, które czasami potrafią zniszczyć, zablokować takie serwisy. Inną rzeczą jest korzystanie i zarabianie z tego typu danych, lub umieszczanie ich dla publiki. Wtedy można, moim zdaniem dyskutować już o przestępstwie.

Konto nie jest Twoje, tylko bank Ci je udostępnia. Tak samo, jak z kartami kredytowymi: karta jest własnością NAZWA BANKU, a nie Twoją.

W tym kraju pod względem prawa w IT nic nie jest w 100% jasne.

Z tym się w 100% zgadzam. Jakkolwiek wykorzystywanie metod biblioteki curl nie jest żadnym przestępstwem, do czasu aż nie narazi się kogoś na straty lub wykorzysta je w niecnym celu i tu chyba nie ma co popadać w paranoje. Gdyby było inaczej wtedy można by było dyskutować czy uznać ją ogólnie za nielegalną i wtedy już z założenia wejście za jej pomocą (bez znaczenia gdzie), czy to na stronę sklepu czy banku byłoby wykroczeniem lub przestępstwem. Ale to jest kręcenie się w kółko, bo ludzie zawsze coś wymyślą. Przynajmniej tak mi się wydaje. I tu można zadać fajne pytanie... Czy interfejsem strony WWW jest protokół HTTP, czy przeglądarka? I kiedy przeglądarka nie jest już przeglądarką? Dla mnie przeglądarka jest po prostu klientem implementującym ten protokół, co i też cURL potrafi.

A pan przeszukujący komputer będzie twierdził inaczej, a'la proces Zatoki Piratów.

Hehe... ciekawe jaki będzie werdykt... jak widzę ich serwis po przerwie, jak narazie działa bez zarzutu