[PHP] [CURL] hele pad in site

[Anoniem: 44718]

Beste leden,

De titel is misschien een beetje vaag, maar ik wist niet hoe ik dit het beste kon omschrijven.
Voor onze webshop kopen wij in bij een groothandel wat nu veel handmatig werk is. Nu hebben wij een alternatieve methode om via CURL al onze producten die geen voorraad meer hebben alvast in de winkelwagen van de groothandel te zetten. Dit is overigens met goedkeuring van de groothandel, welke helaas geen plannen heeft om hier een API voor te ontwikkelen.

Nu log in ik met CURL, zet de data in een COOKIEJAR en deze gebruik ik weer om de producten toe te kunnen voegen aan de winkelwagen. Helaas gaat er bij het toevoegen iets mis aangezien ze na de POST een GET redirect doen wel blijkbaar in hun code staat als /addtocart.php?variabellen.. Nu zet ons systeem voor de /addtocart.php actie onze url in plaats van de url van de leverancier (wat opzich logisch is).

De code die we gebruiken:

PHP:

<?php
        $aData = array('sCode' => 'productcode', 'sAantal' => 1, 'sParam' => '', 'submit1' => 'Toevoegen');

        $ch = curl_init();

        curl_setopt($ch, CURLOPT_COOKIEJAR, "cookies.txt");
        curl_setopt($ch, CURLOPT_COOKIEFILE, "cookies.txt");
        curl_setopt($ch, CURLOPT_URL, "http://www.website.nl/cartadd.asp"); 
        curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
        curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1");
        curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
        curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST");
        curl_setopt($ch, CURLOPT_POST, 1); 
        curl_setopt($ch, CURLOPT_POSTFIELDS, $aData); 
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); 

        $result = curl_exec($ch);
        
        curl_close($ch);
        
        print_r($result);
?>

Kent CURL een variabel om in te stellen dat de url die gebruikt moet worden die van de groothandel is? Heeft iemand hier ervaring mee?

Erwin

[Ventieldopje]

Ik heb geen idee wat je nu precies bedoelt maar hier zou die tussen moeten staan: http://www.php.net/manual/en/function.curl-setopt.php

[Anoniem: 44718]

Ik voer met CURL de volgende URL uit vanaf mijn domein:

http://www.groothandel.nl/addtocart.php deze site doet een redirect naar /cartadd.php, maar voor de / wordt http://www.mijnsite.nl gezet waardoor die doorgezet wordt naar http://www.mijnsite.nl/cartadd.php in plaats van http://www.groothandel.nl/cartadd.php

[MueR]

Dat is niet direct af te vangen. Jij zegt tegen curl dat ie redirects moet volgen, dan doet hij dat. Dan komt ie niet eerst vragen of dit domein wel mag. Helaas.

[RobIII]

MueR schreef op dinsdag 31 mei 2011 @ 23:20:
Dat is niet direct af te vangen. Jij zegt tegen curl dat ie redirects moet volgen, dan doet hij dat. Dan komt ie niet eerst vragen of dit domein wel mag. Helaas.

Wat je wel kunt doen is de redirects niet laten volgen; de headers vervolgens uitlezen van de eerste response en dan zelf een nieuwe GET doen met het juiste domein.

[Anoniem: 44718]

Dan zal ik dus iets moeten verzinnen als Firebug doet? Heb hier al even op zitten google, maar kom weinig opties tegen. Iemand hier als eens ervaring mee gehad?

[thioz]

Even voor mijn beeldvorming,

- je logt in op je eigen site (met curl), haalt daar vanalles op en post dat weer naar de site van de groothandel ? .. dat begreep ik uit : 'Nu log in ik met CURL, zet de data in een COOKIEJAR en deze gebruik ik weer om de producten toe te kunnen voegen aan de winkelwagen.'

- Of doe je per artikel een losse request naar de leverancier ? en haalt de data ergens uit je DB ?

in je voorbeeld doe je trouwens : curl_setopt($ch, CURLOPT_URL, "http://www.website.nl/cartadd.asp");

wat zou betekenen dat je je eigen website aanspreekt ipv die van de groothandel.

[8088]

Anoniem: 44718 schreef op dinsdag 31 mei 2011 @ 23:41:
Dan zal ik dus iets moeten verzinnen als Firebug doet?

Als Firebug wat doet? Het maximum aantal redirects dat gevolgd mag worden definiëer je met CURLOPT_MAXREDIRS, de header uitlezen met curl_getinfo. Staat allemaal op de pagina die Ventieldopje aanhaalde.

offtopic:
Je maakt trouwens wel enorm kromme zinnen. Dat draagt niet echt bij aan het overbrengen van je probleem.

thioz schreef op dinsdag 31 mei 2011 @ 23:50:
in je voorbeeld doe je trouwens : curl_setopt($ch, CURLOPT_URL, "http://www.website.nl/cartadd.asp");

wat zou betekenen dat je je eigen website aanspreekt ipv die van de groothandel.

Ik nam aan dat in dat voorbeeld (in tegenstelling tot het voorbeeld erna) website.nl de website van de groothandel is.

[Voor 49% gewijzigd door 8088 op 31-05-2011 23:53]

[thioz]

@8088 ... dat probleem had ik dus ook

ik zie ook het hele punt niet wat er nu fout gaat ... de hoofdvraag is vooral erg onduidelijk :

'Kent CURL een variabel om in te stellen dat de url die gebruikt moet worden die van de groothandel is? Heeft iemand hier ervaring mee? '

[Anoniem: 44718]

Mijn excuses voor de verwarring met betrekking tot de url in de CURL actie, dit had uiteraard http://www.groothandel.nl moeten zijn.

Misschien nog een staps gewijze uitleg:
1. ik doe een CURL actie naar http://www.groothandel.nl/addtocart.php (dit werkt prima);
2. deze actie doet op de achtergrond een actie naar /cartadd.php?vars... om het product definitief toe te voegen aan de winkelwagen;
3. doordat de groothandel in hun code blijkbaar werken met /cartadd.php in plaats van http://www.groothandel.nl/cartadd.php?vars..., wordt er http://www.website.nl voor de url cartadd.php gezet waardoor die hem probeert uit te voeren op http://www.website.nl/cartadd.php;

Hopelijk geeft dit een beter beeld van het probleem.

Verduidelijking:
http://www.website.nl is de website waar vandaag de CURL uitgevoerd wordt
http://www.groothandel.nl is de website van de groothandel

[Voor 13% gewijzigd door Anoniem: 44718 op 01-06-2011 00:01]

[thioz]

@Piete

Waarom zijn stap 1 en 2 twee losse stappen ? ... je roept toch via curl een url aan en stuurt hierbij toch gegevens door ? mocht de externe pagina hierbij een redirect doen, zal die gewoon uitgevoerd worden op het domein waar je al een request naartoe doet.

- Doe je in stap 2 weet een losse curl request ? ... de uitleg 'deze actie doet op de achtergrond een actie naar ... ' is nog steeds vaag

[Dragor]

Volgensmij bedoelt hij dat www.groothandel.nl/addtocart.php een script is dat een product aan een winkelwagen toevoegt, zoals je dat ook via je browser zou doen. Als dit script klaar is redirect hij (waarschijnlijk via een header("Location: cartadd.php?vars"); ) weer terug naar de winkelwagen om te laten zien aan de klant dat zijn product is toegevoegd. Omdat dit pad relatief is en niet absoluut komt het script van Piete uit op www.website.nl/cardadd.php?vars, waarna hij waarschijnlijk een 404 voor zijn kiezen krijgt.

De oplossing is inderdaad om gewoon tegen CURL te zeggen dat hij niet moet redirecten en indien nodig zelf de winkelwagen van de groothandel ophalen om te kijken of het product toegevoegd is.

Kijk naar de opties CURLOPT_FOLLOWLOCATION en/of CURLOPT_MAXREDIRS zoals al eerder in aangehaald in dit topic.

[thioz]

@Dragor ... ik hou niet zo van speculeren over wat iemand anders bedoeld

... vandaar dat ik hoop dat TS het zelf even duidelijk uitlegt want hij zegt hele andere dingen dan jij interpreteert

[Anoniem: 77516]

thioz schreef op woensdag 01 juni 2011 @ 09:42:
@Dragor ... ik hou niet zo van speculeren over wat iemand anders bedoeld

... vandaar dat ik hoop dat TS het zelf even duidelijk uitlegt want hij zegt hele andere dingen dan jij interpreteert

Nou ik interpreteer het ook op dezelfde manier, als je het goed leest (en het verhaal is inderdaad wel een beetje verwarrend, maar toch) dan bedoelt hij dit.

Zoals Dragor zegt zou ik dus kijken naar de FOLLOWLOCATION optie, en de headers uitlezen, de groothandel.nl domeinnaam hiervoorplakken en een nieuwe CURL request doen, om de inhoud van de winkelwagen te controleren c.q. successmessage.

[Skaah]

Officieel mag je geen Location header sturen met een waarde die niet een URI is (zoals een relatief pad), maar de meeste browsers ondersteunen het prima en dus doet veel software het.

Ik denk inderdaad het het gemakkelijkst zou zijn om de respons van de server te negeren en dan zelf de lijkt met producten in je winkelwagen ophaalt. Dus dan heb je twee CURL opdrachten nodig: ééntje om het product toe te voegen en eentje om te kijken of het daadwerkelijk in je winkelwagentje zit.

[sam.vimes]

Dragor schreef op woensdag 01 juni 2011 @ 08:18:
Volgens mij bedoelt hij dat www.groothandel.nl/addtocart.php een script is dat een product aan een winkelwagen toevoegt, zoals je dat ook via je browser zou doen. Als dit script klaar is redirect hij (waarschijnlijk via een header("Location: cartadd.php?vars"); ) weer terug naar de winkelwagen om te laten zien aan de klant dat zijn product is toegevoegd. Omdat dit pad relatief is en niet absoluut komt het script van Piete uit op www.website.nl/cardadd.php?vars, waarna hij waarschijnlijk een 404 voor zijn kiezen krijgt.

Dat is niet logisch. Zoals Skaah al zei, is een relatieve url in een Location-header niet toegestaan, maar de gebruikelijke actie als protocol en hostnaam worden weggelaten, is ze uit het originele verzoek te halen (dus www.groothandel.nl. Waar komt die tekst www.website.nl dan plotseling vandaan? Verzint curl die spontaan? Want hij komt verder niet voor in de programmacode van Piete.

De oplossing is inderdaad om gewoon tegen CURL te zeggen dat hij niet moet redirecten en indien nodig zelf de winkelwagen van de groothandel ophalen om te kijken of het product toegevoegd is.

cURL gedraagt zich als een browser, en zou dus ook de redirect correct moeten volgen (waarbij de POST wordt veranderd in een GET).

[Dragor]

sam.vimes schreef op woensdag 08 juni 2011 @ 14:27:
[...]

Dat is niet logisch. Zoals Skaah al zei, is een relatieve url in een Location-header niet toegestaan, maar de gebruikelijke actie als protocol en hostnaam worden weggelaten, is ze uit het originele verzoek te halen (dus www.groothandel.nl. Waar komt die tekst www.website.nl dan plotseling vandaan? Verzint curl die spontaan? Want hij komt verder niet voor in de programmacode van Piete.

[...]

cURL gedraagt zich als een browser, en zou dus ook de redirect correct moeten volgen (waarbij de POST wordt veranderd in een GET).

Logisch vind ik het ook niet, maar zo haal ik het uit de tekst van Piete. De URL zou kunnen komen van de server waar het php script van Piete zich op bevind.
Verder zoals je al zegt: de gebruikelijke actie als protocol en hostnaam worden weggelaten, is ... , lijkt mij dus browser-specifiek

Ik kwam net ook nog dit tegen trouwens, zou ook een oorzaak kunnen zijn: http://stackoverflow.com/...263/curl-redirect-problem

[RobIII]

sam.vimes schreef op woensdag 08 juni 2011 @ 14:27:

cURL gedraagt zich als een browser, en zou dus ook de redirect correct moeten volgen (waarbij de POST wordt veranderd in een GET).

Euh, heb je daar een bron van

Dragor schreef op woensdag 08 juni 2011 @ 14:47:
Ik kwam net ook nog dit tegen trouwens, zou ook een oorzaak kunnen zijn: http://stackoverflow.com/...263/curl-redirect-problem

Dat staat ook hier beschreven maar nergens in het verhaal van TS haal ik iets van JS- of meta-redirects

[Voor 43% gewijzigd door RobIII op 08-06-2011 14:50]

[Dragor]

RobIII schreef op woensdag 08 juni 2011 @ 14:48:

[...]

Dat staat ook hier beschreven maar nergens in het verhaal van TS haal ik iets van JS- of meta-redirects

Ik zie ook nergens dat het dat niet is.

Misschien kan de TS hierin helderheid scheppen en/of zijn oplossing plaatsen?

[sam.vimes]

RobIII schreef op woensdag 08 juni 2011 @ 14:48:
[...]

Euh, heb je daar een bron van

• http://curl.haxx.se/docs/manpage.html#-L
• http://curl.haxx.se/docs/httpscripting.html zoek op 9. Redirects

maar ik moet eerlijk zeggen dat ik zo gauw niet kan vinden wat cURL invult als in een Location: responseheader de hostnaam wordt weggelaten. Als cURL daar niet de naam van de host uit het originele request invult, maar "localhost", zou je ongeveer het beschreven gedrag krijgen, maar dan met localhost in plaats van www.website.nl.
TS is daar niet helemaal duidelijk over:

Nu zet ons systeem voor de /addtocart.php actie onze url in plaats van de url van de leverancier

Heeft hij echt de tekst www.website.nl zien staan of concludeert hij dat omdat er een redirect naar zijn eigen host plaatsvindt?

TS zou een hoop wijzer worden als hij het cURL-commando handmatig in een shell zou uitvoeren, met als extra optie --include om ook alle responseheaders te tonen.
Dat zou iets dergelijks worden:

code:

curl --include -L -b cookies.txt -d sCode=productcode -d sAantal=1 -d sParam= -d submit1=Toevoegen http://www.groothandel.nl/cartadd.asp > response.txt

(op 1 regel)

[RobIII]

sam.vimes schreef op woensdag 08 juni 2011 @ 15:41:

• http://curl.haxx.se/docs/manpage.html#-L
• http://curl.haxx.se/docs/httpscripting.html zoek op 9. Redirects

maar ik moet eerlijk zeggen dat ik zo gauw niet kan vinden wat cURL invult als in een Location: responseheader de hostnaam wordt weggelaten.

Ik ben er van op de hoogte dat cURL redirects kan volgen (no shit, daar gaat 't 't hele topic al over ); je bewering was dat cURL zich als een browser zou gedragen. En daar had ik graag een bron van gezien Want inderdaad zal een browser relatieve URL's in Location: headers wel slikken maar AFAIK (en wat volgens TS aan de hand is) doet cURL daar niets mee. Lijkt me ook verrekte stug want cURL mist een heleboel (relevante) context Niet voor niets zijn relatieve URI's niet toegestaan in Location: headers

sam.vimes schreef op woensdag 08 juni 2011 @ 15:41:
Als cURL daar niet de naam van de host uit het originele request invult, maar "localhost", zou je ongeveer het beschreven gedrag krijgen, maar dan met localhost in plaats van www.website.nl.

Dat zeg ik cURL mist context Als 'ie localhost zou gebruiken zou dat een hoop verklaren, maar voor de oplossing die ik al lang geleden aandroeg is dat niet eens boeiend.

[Voor 6% gewijzigd door RobIII op 08-06-2011 16:26]

[sam.vimes]

RobIII schreef op woensdag 08 juni 2011 @ 16:24:
[...]
je bewering was dat cURL zich als een browser zou gedragen. En daar had ik graag een bron van gezien Want inderdaad zal een browser relatieve URL's in Location: headers wel slikken maar AFAIK (en wat volgens TS aan de hand is) doet cURL daar niets mee. Lijkt me ook verrekte stug want cURL mist een heleboel (relevante) context Niet voor niets zijn relatieve URI's niet toegestaan in Location: headers

Het bleef me bezighouden, dus ik heb het even uitgezocht.
Conclusie: cURL gedraagt zich (met optie -L) als een browser: bij een redirect met een onvolledige URI in de Location-header wordt de host:poort van het originele verzoek ingevuld. Sterker nog: cURL hergebruikt zo mogelijk de originele connectie.
(In de sourcecode van cURL is dit terug te vinden in de file transfer.c.)

Dat kan ik dus niet rijmen met wat Piete zegt:

Anoniem: 44718 schreef op dinsdag 31 mei 2011 @ 23:05:
Ik voer met CURL de volgende URL uit vanaf mijn domein:

http://www.groothandel.nl/addtocart.php deze site doet een redirect naar /cartadd.php, maar voor de / wordt http://www.mijnsite.nl gezet waardoor die doorgezet wordt naar http://www.mijnsite.nl/cartadd.php in plaats van http://www.groothandel.nl/cartadd.php

want cURL zou de onvolledige redirect Location: /cartadd.php omzetten naar http://www.groothandel.nl/cartadd.php.

RobIII:
Dat zeg ik cURL mist context Als 'ie localhost zou gebruiken zou dat een hoop verklaren, maar voor de oplossing die ik al lang geleden aandroeg is dat niet eens boeiend.

Ik snap niet precies wat je met het missen van context bedoelt, want er is voldoende context om de redirect uit te voeren: de base-url http://www.groothandel.nl uit de originele POST-url en /cartadd.php uit de Location-header.

De oplossing die je aandraagt is precies wat cURL zelf ook zal doen.

Kennelijk is er wat anders aan de hand wat meer onderzoek vergt.

Kan de TS cURL met de hand uitvoeren met een extra optie -v (verbose)? Zoiets:

code:

curl -v -L -s -b cookies.txt -d sCode=productcode -d sAantal=1 -d sParam= -d submit1=Toevoegen http://www.groothandel.nl/cartadd.asp 2> verbose.txt

en dan de inhoud van verbose.txt posten?

[8088]

Ik heb niet de indruk dat Piete nog geïnteresseerd is in deze discussie.