[php] Callback en missende response

[mr32]

Hoi allemaal. Ik ben voor iemand aan het proberen om via een buitenstaande website in te loggen op een externe server. Het bedrijf van wie de server is, heeft een soort handleiding waarin staat hoe men dat kan doen (in C# ).

Het komt er op neer dat je wat parameters opstuurt met een POST naar de server, dat je vervolgens de session ID terugkrijgt (die je gestuurd had) samen met een token. Deze moet vervolgens weer teruggestuurd worden waarna men een response zou moeten krijgen met failed of success. Klinkt eenvoudig, maar dat viel even tegen.

Het eerste deel leek mij niet zo ingewikkeld: gebruikersnaam en wachtwoord opvangen, een GUID genereren en dat alles in een URL stoppen met cURL. De server zou alles terugsturen naar een callback url. Daar begint het probleem, ik heb een tweede php script, waarnaar in die callbackurl gelinkt wordt. Het probleem is, is dat ik nu helemaal niet weet of dat script nu uitgevoerd wordt, en of ik de juiste gegevens nu terugkrijg. Laat staan dat ik weet hoe ik de gegevens terug krijg (de documentatie is nu zeker niet je van het).

PHP:

$gebruikersnaam = $_POST["gebruikersnaam"];
        $wachtwoord = $_POST["wachtwoord"];
        $callback = 'http://*****/login_afhandeling.php';
        $ssid = NieuwGUID();
        echo "verzoek verzenden met ssid: ".$ssid." <br/>";
        $url = ("https://******.nl/openlogin?sid=".$ssid."&callback=".$callback);   
        echo $url.'<br/>';
        $login = ('username='.$gebruikersnaam.'&password='.$wachtwoord);
        //echo $login.'<br/>';
        //connectie open gooien
        $ch = curl_init();
        //var_dump($login);
        
        //alle data instellen voor POST
        curl_setopt($ch, CURLOPT_URL, $url);
        curl_setopt($ch, CURLOPT_POST, 1);
        curl_setopt($ch, CURLOPT_POSTFIELDS, $login);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

        
        curl_setopt($ch, CURLOPT_VERBOSE, true);
        
        $verbose = fopen('php://temp', 'rw+');
        curl_setopt($ch, CURLOPT_STDERR, $verbose);
        //response code opvragen
        $http_status = curl_getinfo($ch, CURLINFO_HTTP_CODE);
        //curl z'n werk laten doen
        $result = curl_exec($ch);
        //connectie afsluiten
        curl_close($ch);
        
        //response code printen op het scherm
        echo "Eerste response: ".$http_status."<br/>";
        //var_dump($result);
        var_dump($http_status);
        
        !rewind($verbose);
        $verboseLog = stream_get_contents($verbose);
        
        echo "<br/>Verbose informatie:\n<pre>", htmlspecialchars($verboseLog), ",</pre>\n";

Ik krijg daarentegen wel een response van de server. Maar veel stelt het niet voor: een statuscode 0 en een string met een 5 of 4 cijferig nummer (wat zeker geen token kan zijn, het voorbeeld was namelijk veel langer met letters gecombineerd). Daarnaast wordt ook een opmaakloze inlogpagina terug gestuurd.

Deel twee van de afhandeling:

PHP:

    echo $_REQUEST['token'].'<br/>';
    // POST weer opvangen en terugsturen
    $token = $_REQUEST['token'];
    $sid = $_REQUEST['sid'];
    echo "<br/>".$token;
    echo "<br/>".$sid;
    $url = ("https://*****.nl/openlogin/confirm?sid=".$ssid."&callback=http://******/login_afhandeling.php&token=".$token); 
        
    $ch = curl_init();
    
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    
    $response = curl_exec($ch);
    
    $http_status = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    
    curl_close($ch);
    
    echo "Tweede response: ".$http_status.'<br/>';
    var_dump($response);
    
    $session = array(
        'token' => $token,
        'ssid' => $sid);
    setcookie('session', serialize($session), time()+86400);

Maar, de vraag is dus onder andere: hoe vang ik die response terug op. Kan ik dat het beste in één script houden, of moet ik dat verdelen. Het uitlezen van een GET request is het probleem niet, maar hoe weet ik nu of de server die request doorstuurd?

Heeft iemand hier meer ervaring mee? Of kan iemand mij uitleggen hoe dit nu werkelijk in z'n werk gaat. Heel ervaren met PHP ben ik zeker niet, maar met wat puzzelen kan ik meestal toch een heel eind komen.

Alvast bedankt!

[ Voor 42% gewijzigd door mr32 op 22-06-2013 14:04 . Reden: toevoeging script ]

[Styxxy]

Lekker vaag. Je geeft een beetje informatie maar geeft geen details...

[Gomez12]

Gooi gewoon iets als wireshark ertussen (als last resort), bekijk dan de output van het C# programma en van jouw php-progje en maak het gelijk.

En als je niet weet of je 2e script uitgevoerd wordt dan is het gewoon simpel : Debuggen.

[mr32]

Styxxy schreef op zaterdag 22 juni 2013 @ 13:57:
Lekker vaag. Je geeft een beetje informatie maar geeft geen details...

Ik heb de eerste post uitgebreid met de gebruikte scripts. Hopelijk kun je er nu iets meer mee.

Gomez12 schreef op zaterdag 22 juni 2013 @ 14:03:
Gooi gewoon iets als wireshark ertussen (als last resort), bekijk dan de output van het C# programma en van jouw php-progje en maak het gelijk.

En als je niet weet of je 2e script uitgevoerd wordt dan is het gewoon simpel : Debuggen.

Is misschien wel een idee, eerst het programma in C# overschrijven. Ga ik zeker proberen!

[Gomez12]

Grootste fout lijkt mij (als buitenstaander) te zitten in het feit dat jij een GUID aanmaakt en die naar de server toestuurt.
Ik zou als serverbeheerder nooit een GUID van een externe vertrouwen, want ik heb geen idee of die wel goed is opgebouwd en dus wel echt uniek is.

Als serverbeheerder zou ik mogelijk een hash los uitgeven maar dan moet de externe partij (jij dus) ook exact die hash gebruiken en niet zelf een GUID gaan aanmaken. Of de externe partij heeft helemaal niets met de GUID te maken, die gebruik ik enkel intern in de app.

Wat was jouw verwachting toen je las dat je GUID's moest creeeren die de server niet kent en die je wel moet meesturen?

[mr32]

Gomez12 schreef op zaterdag 22 juni 2013 @ 14:15:
Wat was jouw verwachting toen je las dat je GUID's moest creeeren die de server niet kent en die je wel moet meesturen?

Dat niet alleen, ze vragen ook niet om de login gegevens te versleutelen of iets dergelijks. Tenminste, mij lijkt het op zijn minst wel normaal om het wachtwoord als md5 op te sturen.

Mede omdat ik nog niet zo ervaren ben, stond ik er eigenlijk niet bij stil dat het raar is om een GUID op te sturen. Al vond ik het hele systeem nou niet bepaald een stukje hoogstaande veiligheid. Het is helaas niet anders, ik heb daar geen invloed op...

[Wiethoofd]

Neem curl_setopt() eens door. Sowieso handig zijn de volgende twee, de eerste helemaal tijdens het debuggen.

PHP:

 curl_setopt($ch, CURLOPT_HEADER, true);
 curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);

Direct je $_POST["gebruikersnaam"] in de post data dumpen lijkt me ook niet echt netjes.

[mr32]

Even voor mijn eigen begrip: die CURLOPT_FOLLOWLOCATION is er om de server aan te geven dat die externe server mag redirecten naar een andere pagina (in dit geval de pagina die de afhandeling overneemt)?

Dat opvangen en opsturen van de vertrouwelijke gegevens is inderdaad niks. Maar ik denk niet dat ik daar veel aan kan doen

[Gomez12]

mr32 schreef op zaterdag 22 juni 2013 @ 14:21:
[...]
Dat niet alleen, ze vragen ook niet om de login gegevens te versleutelen of iets dergelijks. Tenminste, mij lijkt het op zijn minst wel normaal om het wachtwoord als md5 op te sturen.

Dat is een misvatting, wachtwoorden wil je of plain text hebben (zodat ze op de server versleuteld kunnen worden) of uitgebreid client-side versleuteld hebben (zodat ze op de server verder versleuteld kunnen worden), maar niet enkel met md5 (dan heb je te veel kans op doublures etc)

En in principe is een plain text wachtwoord geen probleem, met een goed ssl-certificaat kan toch niemand het verstuurde zien.

[mr32]

Wat ik op dit moment niet begrijp is het volgende: Ik stuur een callbackURL naar de server, die stuurt waarschijnlijk iets terug naar die url. Wat hoort er nu te gebeuren? Hoort de browser die callback pagina nu te openen? Of draait dat script op de achtergrond? En is die curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true); verantwoordelijk voor het openen van de juiste pagina die door de server wordt opgevraagd?

De server waar deze testpagina's op dit moment op draaien is zo'n vaag gratis geval uit Tsjechië. Deze hebben de php safe mode aanstaan, wat ervoor zorgt dat ik die followlocation van Curl niet in kan schakelen (niet handig )

[Gomez12]

Vraag de externe partij wat er moet gebeuren...Dat hoort of in de documentatie te staan of het hoort duidelijk te zijn.

En kap met dat vage gratis geval, zet dan zelf een wamp/xamp server op op je desktop als test-geval.

[Wiethoofd]

Zet headers aan en dump gewoon de output die je krijgt. Met followlocation worden eventuele uitgezonden header()s gevolgd, mocht de inlogpagina je normaliter doorverwijzen naar een landingspagina of profielpagina oid.

[Jimbolino]

als je wil weten of de callback url aangeroepen wordt, zet er een simpele mail() functie in, of kijk in de access log van apache...

[Cartman!]

Gomez12 schreef op zondag 23 juni 2013 @ 13:44:
En kap met dat vage gratis geval, zet dan zelf een wamp/xamp server op op je desktop als test-geval.

QFT, lokaal kun je t meeste werkend krijgen en anders moet je gewoon een degelijke hostingaccount hebben waar je je spullen kunt testen. PHP safe mode is al een tijdje depricated ook dus je hosting is antiek

mr32 schreef op zondag 23 juni 2013 @ 13:28:
Wat ik op dit moment niet begrijp is het volgende: Ik stuur een callbackURL naar de server, die stuurt waarschijnlijk iets terug naar die url. Wat hoort er nu te gebeuren? Hoort de browser die callback pagina nu te openen? Of draait dat script op de achtergrond?

Tenzij de server javascript redirect returnt en jij deze op je scherm print zonder escaping gaat die externe server jouw browser nooit kunnen laten redirecten. Wat er wel hoort te gebeuren kunnen wij niet ruiken, lees de documentatie eens door. Hoe je het moet verdelen is aan jou, als jij het in 2 files handiger vind dan doe je dat. Wil je het in 1 hebben, doe dat.

[ Voor 46% gewijzigd door Cartman! op 24-06-2013 11:59 ]

[mr32]

Cartman! schreef op maandag 24 juni 2013 @ 11:54:
Tenzij de server javascript redirect returnt en jij deze op je scherm print zonder escaping gaat die externe server jouw browser nooit kunnen laten redirecten. Wat er wel hoort te gebeuren kunnen wij niet ruiken, lees de documentatie eens door. Hoe je het moet verdelen is aan jou, als jij het in 2 files handiger vind dan doe je dat. Wil je het in 1 hebben, doe dat.

Ik zal eens kijken of ik in contact kan komen met die gasten. Bedankt voor je reactie!

Mijn laatste vraagje nog:
Stel dat ik het in één file doe (wat voor mij in eerste instantie de bedoeling was), hoe weet ik dan dat de server een request naar die file stuurt? Ik neem aan dat het onzin is om een loopje te laten draaien tot de server iets terug stuurt (toch??? )

[Gomez12]

mr32 schreef op maandag 24 juni 2013 @ 12:04:
[...]
Mijn laatste vraagje nog:
Stel dat ik het in één file doe (wat voor mij in eerste instantie de bedoeling was), hoe weet ik dan dat de server een request naar die file stuurt? Ik neem aan dat het onzin is om een loopje te laten draaien tot de server iets terug stuurt (toch??? )

Ik zou een callback altijd interpreteren als dat de server een losse call doet naar je pagina en dat je apache wel het loopje draait...

Maar wederom : Vraag die gasten het gewoon.

Wij kunnen zonder documentatie, zonder voorbeelden etc wel gaan zitten gokken. Maar die gasten kunnen je exact vertellen hoe het zit, wellicht dat ze zelfs een php-voorbeeld gewoon ergens hebben liggen...

[Janoz]

mr32 schreef op zondag 23 juni 2013 @ 13:28:
Wat ik op dit moment niet begrijp is het volgende: Ik stuur een callbackURL naar de server, die stuurt waarschijnlijk iets terug naar die url. Wat hoort er nu te gebeuren? Hoort de browser die callback pagina nu te openen? Of draait dat script op de achtergrond? En is die curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true); verantwoordelijk voor het openen van de juiste pagina die door de server wordt opgevraagd?

Nee, er gebeurt waarschijnlijk precies wat je zelf zegt.

Jij stuurt een verzoek naar de server met een callback url. De server roept vervolgens die callback url op. Hoe kom je er bij dat de browser vervoglens die URL moet openen? Je browser is niet degene die die URL oproept, dat is zeer waarschijnlijk die andere server. Die andere server roept een URL aan op je tjechische host. Dat heft verder helemaal niks met curl of de browser of je huidige script te maken.

Misschien is het handiger voor te stellen met een telefoon. Jij belt je server in tjechie om dat eerste script uit te voeren. Dat script belt vervolgens naar die server van die andere partij en geeft ze een telefoonnummer mee waarop ze terug kunnen bellen met het antwoord. De server van die andere partij hangt de telefoon op. Je script geeft nog even wat debuginformatie (of wat je ook maar voor meuk na die curl had staan) terug aan jou en hangt de telefoon ook op.

Vervolgens belt de server van de die andere partij naar het telefoonnummer dat hij gekregen heeft (wat waarschijnlijk ook een nummer is van die server in tsjechie ) en geeft de informatie door. Dat is de 'callback'. Het eerste script en jij merken hier dus helemaal niks van!


Als je dit begrijpt is het neem ik aan ook evident waarom je dit asynchrone gedrag niet met 1 script kan doen.

[Wiethoofd]

Zet nou voor de gein eens de curlopt header aan en doe een print_r of een var_dump van de curl_exec(), dan zie je welke headers en data de server je terugstuurt, waar je via omgeleid wordt etc.

[Slurpie]

Ziet er uit als een vrij slechte Oauth implementatie.

Maar je kan wel naar voorbeelden kijken hoe Oauth werkt, en dat als basis gebruiken.
Daar worden de callback en dergelijke ook in gebruikt. Zie je gelijk waarom je het niet in 1 file wilt hebben.

[mr32]

Janoz schreef op maandag 24 juni 2013 @ 13:50:
Misschien is het handiger voor te stellen met een telefoon. Jij belt je server in tjechie om dat eerste script uit te voeren. Dat script belt vervolgens naar die server van die andere partij en geeft ze een telefoonnummer mee waarop ze terug kunnen bellen met het antwoord. De server van die andere partij hangt de telefoon op. Je script geeft nog even wat debuginformatie (of wat je ook maar voor meuk na die curl had staan) terug aan jou en hangt de telefoon ook op.

Leuk voorbeeld! Maakt het meteen duidelijk. Maar zo is het voor mij dus lastiger om dat tweede script te debuggen? Aangezien ik dus niet de info direct op het scherm kan laten printen.

Wiethoofd schreef op maandag 24 juni 2013 @ 13:51:
Zet nou voor de gein eens de curlopt header aan en doe een print_r of een var_dump van de curl_exec(), dan zie je welke headers en data de server je terugstuurt, waar je via omgeleid wordt etc.

Heb ik tot op zekere hoogte al gedaan, maar ik zal er deze keer die curlopt header er eens bijplaatsen. Dank!

Slurpie schreef op maandag 24 juni 2013 @ 13:56:
Ziet er uit als een vrij slechte Oauth implementatie.

Maar je kan wel naar voorbeelden kijken hoe Oauth werkt, en dat als basis gebruiken.
Daar worden de callback en dergelijke ook in gebruikt. Zie je gelijk waarom je het niet in 1 file wilt hebben.

Ben benieuwd wat dat gaat opleveren, ik ga meteen zoeken!

[Styxxy]

mr32 schreef op dinsdag 25 juni 2013 @ 07:30:
[...]
Leuk voorbeeld! Maakt het meteen duidelijk. Maar zo is het voor mij dus lastiger om dat tweede script te debuggen? Aangezien ik dus niet de info direct op het scherm kan laten printen.

Inderdaad, dat was een zeer goede analogie.

Om jouw script te debuggen: je kan ook altijd een bestandje weg schrijven ipv "echo" of "print_r" te doen hoor .

[mr32]

Styxxy schreef op dinsdag 25 juni 2013 @ 12:16:
[...]
Om jouw script te debuggen: je kan ook altijd een bestandje weg schrijven ipv "echo" of "print_r" te doen hoor .

Gaan we meteen proberen

Edit: Met de afhandeling is niks mis, tenminste, zover ik het kan testen. Ik krijg in mijn gegenereerde bestand keurig alle waardes te zien die ik wil zien, behalve de teruggestuurde ssid en token. Die worden schijnbaar niet meegestuurd. Ik denk dat ik op basis van deze gegevens kan stellen dat er mijn eerste script iets fout gaat. Ik snap nu tenminste wel wat er nu gebeurd met de server, alleen komen mijn gegevens niet helemaal aan als gewenst (tenminste, dat denk/hoop ik).

[ Voor 48% gewijzigd door mr32 op 25-06-2013 14:57 . Reden: tips uitgeprobeerd ]

[Wiethoofd]

Zet een kale testcase op waarin je headers enabled, follow redirects, returntransfer en je postfields invult (en de standaard curlopts die je nodig hebt).

Doe een print_r van je curl_exec en bekijk eens welke response headers je terug krijgt ipv hier te melden dat het niet werk gewoon zo kaal mogelijk testen en vervolgens functionaliteit toevoegen, debugging commenten etc.....

[mr32]

Ik ben benieuwd of jullie hier iets mee kunnen. Ik heb het volgende script:

PHP:

<?php
    verstuurRequest();
    
    function NieuwGUID() {
        $s = strtoupper(md5(uniqid(rand(),true)));
        $guidTekst = 
            substr($s,0,8) . '' .
            substr($s,8,4) . '' .
            substr($s,12,4) . '' .
            substr($s,16,4). '' .
            substr($s,20);
        return $guidTekst;
    }
    
    function verstuurRequest() {
        $gn = 'gebruikersnaam';
        $ww = 'wachtwoord';
        
        $callback = 'http://********.ch/*******/login_afhandeling.php';
        $ssid = NieuwGUID();
        
        $url = ('https://*******.nl/openlogin?sid='.$ssid.'&callback='.$callback);
        
        $login = ('username='.$gn.'&password='.$ww);
        
        $ch = curl_init();
        
        curl_setopt($ch, CURLOPT_URL, $url);
        curl_setopt($ch, CURLOPT_POST, 1);
        curl_setopt($ch, CURLOPT_POSTFIELDS, $login);
        curl_setopt($ch, CURLOPT_HEADER, true);
        curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
        curl_setopt($ch, CURLOPT_VERBOSE, true);
            
        $verbose = fopen('php://temp', 'rw+');
        curl_setopt($ch, CURLOPT_STDERR, $verbose);
        
        $response = curl_exec($ch);
        
        curl_close($ch);
        
        print_r($verbose);
        echo '-----------------------';
        print_r($response);
    }

    
?>

en de volgende output:



Ik heb hem uitgevoerd op een compleet andere server van een vereniging waar ik de site van onderhoud, waarvan ik zeker wist dat alles gewoon up-to-date en in orde was.

Als ik de callback en ssid weghaal (of beter gezegd op null zet), krijg ik hetzelfde resultaat, alleen zonder form en menu.

Die Resource ID #3 is trouwens een domme fout, maar het vervelende is, is dat ik hem niet uitgelezen krijg. Ik krijg anders een lege output met heel veel spaties en vervolgens de volgende print_r.

EDIT 2 Ik heb opnieuw nieuws: de vereniging waarvoor ik dit doe, heeft besloten ontevreden te zijn met dit systeem (waar ik dus op moet inloggen) en er zijn dus plannen om over te stappen naar iets anders. Mede met de boodschap dat ik deze feature dus mag laten vallen. Bedankt iedereen!

[ Voor 15% gewijzigd door mr32 op 26-06-2013 17:34 ]