[PHP] Image returnen met curl

[Kaastosti]

Er zijn genoeg tutorials over hoe curl in elkaar steekt, ik heb alleen nog nergens kunnen vinden hoe je gewoon een image ophaalt en returned. Uiteindelijk moet het een image worden die van een beveiligde server komt met username en wachtwoord, maar om te proberen heb ik het simpel proberen te houden.

Toch krijg ik alleen maar raw output terug. De output bevat wel stukjes die me ok lijken (de camera waarmee de foto gemaakt is, het bewerkingsprogramma waar hij in op is geslagen etc.). Alleen wordt de code niet herkent alszijnde een jpg. Ik dacht dat ik dat met die Content-Type onderving, maar helaas...

PHP:

$ch = curl_init();
curl_setopt($ch, CURLOPT_HTTPHEADER, Array("Content-Type: image/jpeg"));
curl_setopt($ch, CURLOPT_URL, "http://members.ams.chello.nl/e.venema4/images/got/case_small.jpg");
$result = curl_exec($ch);
echo $result;

[Erkens]

je moet naar de browser ook de content-type doorsturen natuurlijk

PHP:

header("Content-Type: image/jpeg");
echo $result;

[Kaastosti]

Aha als ik dat bovenaan zet werkt het... maar wat nu als ik dat plaatje ergens halverwege een pagina moet laden? Dan is er sowieso al header data verstuurd en wordt die header() functie verder niet meer aangesproken.

Maakt het uit als ik die er sowieso boven zet? Ik vind het een beetje lelijk om dat nu boven elke pagina te zetten waar ik ergens een plaatje in plak met curl

[Erkens]

volgens mij maak jij een denkfout
in je HTML include je geen plaatje, je linkt naar een plaatje

HTML:

[img]"url/naar/plaatje.php"[/img]

plaatje.php dient dan _alleen_ dat plaatje als output te hebben, en niks anders

[Kaastosti]

Ahaa en dan kun je de url gebruiken om de naam van het plaatje te achterhalen en deze vervolgens te returnen met in die plaatje.php de header() er al ingeplakt Of ik bouw er gewoon een functie van, lijkt me ook werken?

HTML:

[img]'".getStats('plaatje.jpg')."'[/img]

[ Voor 28% gewijzigd door Kaastosti op 01-03-2005 16:44 ]

[Erkens]

Kaastosti schreef op dinsdag 01 maart 2005 @ 16:42:
Ahaa en dan kun je de url gebruiken om de naam van het plaatje te achterhalen en deze vervolgens te returnen met in die plaatje.php de header() er al ingeplakt Of ik bouw er gewoon een functie van, lijkt me ook werken?

HTML:

[img]'".getStats('plaatje.jpg')."'[/img]

zolang die functie getStats() maar een geldige URL teruggeeft kan dat ja

[Kaastosti]

Hmm het idee is leuk, maar ik blijf met die header zitten. Ik heb die header nodig om het plaatje te laten zien, maar moet ik 'm dan in elk bestand er bij zetten? Hij staat nu in de functie, maar die vindt dat logischerwijs niet echt tof

[Erkens]

Denk eens goed na wat er gebeurd op het moment dat een browser een HTML pagina download en wilt weergeven.
Zodra de browser een img-tag tegenkomt gaat hij het plaatje downloaden wat daar moet komen te staan in dit geval "plaatje.php". De oorspronkelijk html pagina (wat uiteraard ook PHP kan zijn) heeft niks met dat plaatje te maken, het moet alleen de juiste URL geven naar het plaatje wat weergeven wordt door dat andere scriptje "plaatje.php"

[Kaastosti]

Dat snap ik, daarbij ondervind ik alleen 2 kleine probleempjes:
- Het plaatje bevat variabelen, die moet ik dus meegeven aan die pagina
- De header kan niet bij het plaatje gevoegd, het slaat immers op de pagina zelf
Ik speel al geruime tijd met PHP en weet dat die headers altijd als eerste verstuurd moeten worden. Tenzij ik dus een pagina laad (bijv. in een apart frame, zodat alle referenties met de parent-pagina verdwijnen) krijg ik gedonder met een header aanpassing, aangezien die allang verstuurd zijn

Misschien dat ik er helemaal verkeerd tegenaan kijk hoor, please correct me if I'm wrong

Nieuwe poging:
Apart bestand gemaakt genaamd image.php
In m'n index.php gezet: [img]'image.php?name=plaatje'[/img]

In image.php wordt die header gezet, curl gestart, de hele zooi uitgelezen en dan... niets. Kan een pagina ook een image returnen? Iets als return $image lijkt me niet van toepassing, aangezien het geen functie betreft.

[ Voor 23% gewijzigd door Kaastosti op 01-03-2005 17:07 ]

[beetle71]

In image.php wordt die header gezet, curl gestart, de hele zooi uitgelezen en dan... niets. Kan een pagina ook een image returnen? Iets als return $image lijkt me niet van toepassing, aangezien het geen functie betreft.

Zo moet het ook, maar hoezo returnen? het image.php script mag gewoon
echo $image doen nadat je die content-type header hebt verstuurd. En verder moet/mag het helemaal niks doen.

[Kaastosti]

Mjah dacht ik ook... dit heb ik nu in image.php staan:

PHP:

<?
header("Content-Type: image/jpeg");
$ch = curl_init();
curl_setopt($ch, CURLOPT_HTTPHEADER, Array("Content-Type: image/jpeg");
curl_setopt($ch, CURLOPT_URL, "http://members.ams.chello.nl/e.venema4/images/got/".$_GET['name'].".jpg");
$result = curl_exec($ch);
echo $result;
?>

[beetle71]

Volgens mij mag/moet die regel met CURLOPT_HTTPHEADER zowieso al weg. Je hoeft in je requestheader niet te zeggen welk contenttype je verwacht!

Let er verder op dat je GEEN whitespaces meer hebt staan NA en VOOR je <? en ?> !

En ten derde: (NOFI) Weet je zeker dat curl_init() uberhaupt werkt in je systeem (het moet namelijk met php meegecompileerd zijn --with-curl en olgens mij is dat standaard NIET zo.

[Kaastosti]

Ik draai debian... apt-get install php4-curl werkt ook Getest

Maar is die CURLOPT_HTTPHEADER dan geen vervanging van header()? Ik vond 'm nou juist zo mooi in het geheel passen

[ Voor 47% gewijzigd door Kaastosti op 01-03-2005 17:42 ]

[Morrar]

Waarom gebruik je niet gewoon iets als fpassthru() ? Als je basic authentication van Apache gebruikt werkt dat prima. Een scriptje als:

PHP:

header("Content-type: image/jpeg");
$handle = fopen('http://<user>:<passwd>@www.site.nl/protected_dir/image.jpg', 'rb');
fpassthru($handle);
exit;

is dan afdoende...

[beetle71]

Maar is die CURLOPT_HTTPHEADER dan geen vervanging van header()? Ik vond 'm nou juist zo mooi in het geheel passen

Nee! Die CURLOPT_HTTPHEADER is een request header die jij VERSTUURT aan de server waar het plaatje vandaan moet komen. De header("Content-Type: image/jpeg"); die je zet wordt verstuurd naar de 'eindgebruiker', dus diegene die vanuit de browser het plaatje opvraagt

[Kaastosti]

Het idee van de passthru is erg mooi, die heb ik geprobeerd te implementeren. Hij laat echter met geen mogelijkheid dat plaatje zien. De uiteindelijke url klopt, als ik die direct ingeef krijg ik ook een grafiek terug, maar in script werkt het gewoon niet

Ik heb het exact nagebouwd zoals Morrar het voordoet, maar er komt helemaal niets uit.

HTML:

<imf src='image.php?name=blaat'>

In image.php kan ik niets echo-en, aangezien alles een image is dus even makkelijk checken welke vars er daar gebruikt worden zit er ook niet in.

[Morrar]

Als je geen content-type header meegeeft (dus ff het header() statement wegcomment) dan krijg je wel gewoon foutmeldingen op het scherm (je zou ze ook kunnen laten loggen trouwens). Surf je gewoon met je browser naar die image.php. Het voorbeeld dat ik je gaf heb ik hier getest en werkte (haalde plaatje van een andere beveiligde server en toonde het). Denk dus dat je plaatje niet goed staat of je name niet goed in een dir / url verwerkt wordt oid.

//Edit: vergeet idd die security opmerking... Als je een server zo geconfigged hebt dat dat kan is het wel triest

//Edit2: hmmz dat is vreemd, ook als je er met je browser heen surft (dus niet naar de pagina met de <img> tag maar naar image.php zelf)?!? Post anders een de code en de URL van het plaatje enzo...

[ Voor 59% gewijzigd door Morrar op 02-03-2005 15:11 ]

[Kaastosti]

Alles draait in een root jail, waar je niet uit kan Security op input is een volgend onderdeel, als het eerst maar eens werkt Maar als ik die header er uit sloop kan ik nog steeds niet echo-en

[ Voor 22% gewijzigd door Kaastosti op 02-03-2005 15:06 ]

[simon]

Kaastosti schreef op woensdag 02 maart 2005 @ 14:36:
Het idee van de passthru is erg mooi, die heb ik geprobeerd te implementeren. Hij laat echter met geen mogelijkheid dat plaatje zien. De uiteindelijke url klopt, als ik die direct ingeef krijg ik ook een grafiek terug, maar in script werkt het gewoon niet

Ik heb het exact nagebouwd zoals Morrar het voordoet, maar er komt helemaal niets uit.

HTML:

<imf src='image.php?name=blaat'>

In image.php kan ik niets echo-en, aangezien alles een image is dus even makkelijk checken welke vars er daar gebruikt worden zit er ook niet in.

tuurlijk wel, je haalt die headers weg en checkt 'm in firefox. Kijkt of het misgaat et poef. Klaar. Het is wel een heel erge manual vraag

[Kaastosti]

Gast... wat denk je dat ik doe dan? Ik echo alles, probeer $_SESSION vars te zetten om die later uit te lezen... forget it, geen info Okee, het hoort niet, maar ik heb allerlei omwegen geprobeerd zonder resultaat.

Ik vermoed dat, aangezien de pagina opgeroepen wordt alszijnde image (door de html tag), hij ook alle eventuele resultaten, echo's etc. van die pagina in die image wil proppen. En daar zie ik dan natuurlijk niets van terug op de pagina, behalve een broken link

PHP:

$url = "https://username:[e-mail]/".$var.".png";
fopen($url, "rb");

Hij geeft nu na ongeveer alles uitzetten aan dat hij het bestand niet kan vinden. En als ik dan doodleuk die url in de browser plak.. tadaaa grafiek

[ Voor 59% gewijzigd door Kaastosti op 02-03-2005 15:22 ]

[simon]

Wat ik bedoel is open die link in je browser ipv enorm moeilijk te doen...

[Morrar]

Het is een HTTPS-verbinding? Even kijken of fopen() daarmee overweg kan... HTTPS zou gewoon moeten werken volgens de manual.

Sowieso is het een PNG dus en geen JPEG, dus moet de Content-type header ook zijn image/png. Maar goed. Eens kijken. Kun je eventueel het echte adres van dat image hier posten (zit nu nog niet in een beveiligde dir toch)?

Je zou trouwens ook de settings voor safe_mode en allow_url_fopen even moeten checken (kan met phpinfo() )

Edit:
@Simon, volgens mij heeft ie dat nu door en gedaan... Image kan niet gevonden worden is de error dus es kijken...

[ Voor 35% gewijzigd door Morrar op 02-03-2005 15:31 ]

[beetle71]

Wat krijg je dan als je die headers weghaalt en je gewoon http://www.blablabl.nl/image.php IN JE BROWSER balk typt. Dat moet gewoon output genereren.

Ten tweede: binnen het image.php script mag je niet zomaar sessions gebruiken. Je moet dan

PHP:

session_cache_limiter('private');

in je script gebruiken, anders wordt de session header terug gestuurd naar de browser en die snapt er niks meer van, denkt: 'Waarom heeft een plaatje session data?!?!" en geeft een error (Dit geld in ieder geval voor IE)

[Kaastosti]

Wat ik bedoel is open die link in je browser ipv enorm moeilijk te doen...

Van een secure server, zodat alles en iedereen de gebruikersnaam en het wachtwoord kan zien, nee bedankt

Sowieso is het een PNG dus en geen JPEG, dus moet de Content-type header ook zijn image/png.

Die had ik inmiddels ook al aangepast

safe_mode is off
allow_url_fopen is on

Als ik de url gewoon in de browser invul werkt het, dus ik denk dat de suggestie dat het aan restricties van fopen ligt wel kan kloppen. Eens even in de security settings daar duiken

Wat wel gebeurt is dat hij bij het weergeven van de URL met vars de username en het password vervangt door '...'. Ik ga er dan maar van uit dat hij dat doet uit veiligheidsoverwegingen. Als ik namelijk die url gewoon pak en daar username en wachtwoord aan toevoeg krijg ik netjes het plaatje te zien.

[ Voor 21% gewijzigd door Kaastosti op 02-03-2005 15:45 ]

[Morrar]

> Van een secure server, zodat alles en iedereen de gebruikersnaam en het wachtwoord kan zien, nee bedankt

Hij bedoeld allen voor nu om te testen. Dan is het toch niet zo erg? Of heb je daar hordes mensen die over je schouder staan mee te kijken voor het user + pass?

> Wat wel gebeurt is dat hij bij het weergeven van de URL met vars de username en het password vervangt door '...'.

In de foutmelding van PHP bedoel je neem ik aan?

> Als ik namelijk die url gewoon pak en daar username en wachtwoord aan toevoeg krijg ik netjes het plaatje te zien.

Kortom: het URL wordt goed opgebouwd, maar het inloggen met user:pass@server gaat niet goed... Vreemd. Maar als je die img nu in een niet beveiligde dir zet op dezelfde (secure) server, werkt t dan wel (dan heb je immers geen user + pass meer in de URL)? Kun je testen of fopen met HTTPS-urls an sich wel goed werken in je PHP-installatie... Overigens draait die server wel op poort 443 mag ik hopen.

Edit: Overigens gebruikt PHP het HTTP 1.0 protocol, en je server wellicht het HTTP 1.1 protocol. Een user-agent instellen met ini_set() is dan de oplossing...

ini_set('user_agent','Mozilla: (compatible; Windows XP)');

EN:

"Note: HTTPS is supported starting from PHP 4.3.0, if you have compiled in support for OpenSSL." !

[ Voor 29% gewijzigd door Morrar op 02-03-2005 16:03 ]

[kunnen]

Tip:

Gebruik

PHP:

ob_start();  //ob = Output Buffering


//...

$content = ob_get_contents(); 
ob_end_flush();    

echo $content;

Daarmee ondervang je het probleem van headers versturen?

[ Voor 14% gewijzigd door kunnen op 02-03-2005 19:00 ]

[Kaastosti]

Het headers versturen is alleen een issue als ik 'm gewoon aanroep binnen een andere pagina, en niet als image. Dan wil hij namelijk headers gaan veranderen als er al een heel framework omheen zit. Om daar te beginnen met output buffering is onbegonnen werk

Als het alleen dat bestand geweest zou zijn... dan was het inderdaad een mogelijke oplossing geweest. Ik denk dat ik gewoon wat verder klooi met de security settings van php en fopen settings, het moet toch kunnen

[beetle71]

Kaastosti schreef op donderdag 03 maart 2005 @ 13:48:
Het headers versturen is alleen een issue als ik 'm gewoon aanroep binnen een andere pagina, en niet als image. Dan wil hij namelijk headers gaan veranderen als er al een heel framework omheen zit. Om daar te beginnen met output buffering is onbegonnen werk

Als het alleen dat bestand geweest zou zijn... dan was het inderdaad een mogelijke oplossing geweest. Ik denk dat ik gewoon wat verder klooi met de security settings van php en fopen settings, het moet toch kunnen

Huh?! Ik heb het gevoel dat je toch nog steeds iets niet begrijpt. (NOFI) Waarom zeg je 'als er al een heel framework omheen zit' ?

als ik 'm gewoon aanroep binnen een andere pagina, en niet als image.

Hoe kun je een image nu niet als image aanroepen? Als je een image binnen een andere pagina oproept is en blijft het toch ook een image. Of probeer je 'm op te halen om 'm daarna in een database te stoppen of te bewerken met GD-lib of op te slaan op je locale disk.

Om een 'passthru' scriptje van een image KAN niks omheen zitten. Zo'n scriptje haalt ergens anders een plaatje op, verstuurt de benodigde header aan de browser en stuur het plaatje door. MEER NIET! Wat wil jij hier omheen zetten

Probeer nog eens uit te leggen wat je nou wilt bereiken.

edit:

vvvv @morrar: mmmm, het gaat hier inmiddels overal en nergens over, maar ik heb het idee dat er in dit topic een beetje langs elkaar heen wordt gepost en de topicstarter iets niet helemaal snapt.

[ Voor 24% gewijzigd door beetle71 op 03-03-2005 14:31 ]

[Morrar]

Dit topic gaat zo langzamerhand over van alles en nog wat... Kernprobleem is dat hij het plaatje niet kan vinden in die fopen lijkt me... Daar kunnen allerlei redenen voor zijn, heb er zlef 2 genoemd:

quote: myself

:
Overigens gebruikt PHP het HTTP 1.0 protocol, en je server wellicht het HTTP 1.1 protocol. Een user-agent instellen met ini_set() is dan de oplossing...

ini_set('user_agent','Mozilla: (compatible; Windows XP)');

EN:

"Note: HTTPS is supported starting from PHP 4.3.0, if you have compiled in support for OpenSSL." !

Daar nu al naar gekeken?

[Kaastosti]

Waarom zeg je 'als er al een heel framework omheen zit' ?

Wat ik daar bedoel, is dat de headers op dit moment niet het probleem zijn. Aangezien de image.php aangeroepen wordt als image ([img]'image.php?name=blaat'[/img]) is er verder nog niets, dus kunnen er daar headers verstuurd worden.

Als ik zeg maar image.php gewoon zou includen, wordt deze opgenomen in de parent-pagina, waar al headers verstuurd zijn. Daar zouden problemen ontstaan (met framework bedoel ik onderandere die parent-pagina). In dit geval is dat niet zo, dus is output buffering hier niet nodig.

Hoe kun je een image nu niet als image aanroepen?

Als ik die pagina aanroep binnen een <img> tag, roep ik 'm als image aan. Als ik die pagina include alszijnde pagina (include('image.php')), dan wordt het een pagina.

"Note: HTTPS is supported starting from PHP 4.3.0, if you have compiled in support for OpenSSL." !

PHP Versie 4.3.10 draait hier, ik zal even kijken of OpenSSL meegecompiled is

_{Ik geef toe dat het topic een beetje allerlei onderwerpen aan het beslaan is... het kan best zijn dat ik ergens een denkfout maak hoor. Zelf werk ik al een aantal jaren met php, alleen heb ik daar nooit iets dergelijks hoeven doen, dus op dit gebied ontbreekt de kennis nog een beetje}

[beetle71]

Kaastosti schreef op donderdag 03 maart 2005 @ 16:48:
[...]
Als ik die pagina aanroep binnen een <img> tag, roep ik 'm als image aan. Als ik die pagina include alszijnde pagina (include('image.php')), dan wordt het een pagina.
[...]

Mmm.. had ik het dus toch goed... Wat wil je in godsnaam bereiken met

PHP:

include('image.php'),

Dat het plaatje in die pagina verschijnt Een passthru script of wat dan ook dat je maak zul je NOOIT kunnen includen.

Ik concludeer dat je ongeveer zoiets wilt bereiken:

PHP:

// vanalles en nog wat...
echo 'Dit is een html pagina met een plaatje <br/>';
include('image.php');
echo 'En zo eindigt de pagina<br/>';

Of zit ik er nu helemaal naast en begrijp ik je voor geen meter ?!?

Als je een plaatje in een HTML pagina wilt opnemen zul ALTIJD van een <IMG> tag gebruik moeten maken die een plaatje(=file) aanroept. Die kun je dus niet al in je pagina 'embedden'(zoals dat in emals wel kan), het moet dus ongeveer zo: (of probeer je een htmlmail te genereren?)

PHP:

// vanalles en nog wat...
echo 'Dit is een html pagina met een plaatje <br/>';
echo '[img]"image.php?plaatje=filenaam">';
echo[/img]';

en dan een image.php script dat dat plaatje doorsluist.

/me vraagt zich af of 'ie van de wens van de TS helemaal niks snapt en hier dus een ongeloofelijk 'offtopic' verhaaltje zit te vertellen.

[Morrar]

Ok even duidelijkheid scheppen in dit topic wat uit de hand loopt. Er zijn 2 mogelijke scenario's: 1 = testen, 2 is definitieve versie.

Scenario 1)
Testscenario, dus errors in het scherm van de browser:

image.php

code:

<?PHP
$handle = fopen('http://user:[e-mail]/dir/image.png');
?>

Vervolgens *surf je direct met je browser naar image.php*. Dus http://www.andereserver.nl/image.php *rechtsstreeks* in de adresbalk van je browser rammen. Niks includen in andere files, niks geen img-tag, gewoon je browser pakken en image.php openen!! Codeer in image.php hard de URL, user, pass alles. Pas als die fopen() geen fout meer geeft ga je naar scenario 2!

Scenario 2)
Definitieve versie

image.php

code:

<?PHP
header('Content-type: image.png');
$handle = fopen('http://user:[e-mail]/dir/' . $_GET['name'] . '.png');
fpassthru($handle);
?>

Let op de header() hier en let op de fpassthru(). Let er ook op dat er GEEN whitespace voor of na de <?PHP en ?> tags staat!

In dit scenario toon je het plaatje in een ander bestand met:

code:

<html>
<head></head>
<body>
[img]"http://www.andereserver.nl/image.php?name=blaat">
</body>
</html[/img]

Foutmeldingen worden nu niet getoond!! Als er een fout optreed wordt er simpelweg geen plaatje getoond maar een browsericoontje dat het plaatje niet werkt...

Kortom het is OF scenario1 OF scenario2... Verder ongein met include() en sessions en wat dan ook is onnodig... Begin dus met scenario 1 tot die fopen() geen fout meer geeft en doe dan pas scenario 2... Duidelijker dan dit kan ik het echt niet brengen...

[ Voor 27% gewijzigd door Morrar op 04-03-2005 00:00 ]

[Kaastosti]

@beetle71: Die include was alleen maar even om mogelijke foutmeldingen op het beeld te krijgen en om ook variabelen te kunnen echo-en om te kijken of die uiteindelijk inderdaad wel kloppen. Dat was de enige reden waarom ik dat bestand even in een include schopte. Dat dat totaal geen zin heeft als ik ook echt dat plaatje wil laten zien lijkt me logisch

@Morrar: Ik ga het eens rustig stap voor stap proberen, want zoals ik het nu heb kan het probleem bij teveel mogelijke variabelen liggen; settings van php, settings van fopen, versies etc.

Update:
Okee na het uitgebreid testen kom ik toch uiteindelijk bij wat Morrar al eerder heeft gezegd over PHP met OpenSSL. Het invullen van de exacte url in de browser geeft netjes het plaatje, in script krijg ik echter een fopen() error dat de stream niet goed is. Ik kan me niet anders voorstellen dan dat het aan de support voor https ligt, die er alleen is als je OpenSSL meecompiled bij installatie.

De installatie van PHP is gegaan via het apt-get systeem, waar geen openssl bij staat. Ook bij het zoeken binnen apt-get komt het niet terug. Ik ben bang dat dat dus een potje php-opnieuw-installeren wordt, deze keer _met_ OpenSSL support.

Bedankt voor alle suggesties en geduld

[ Voor 40% gewijzigd door Kaastosti op 04-03-2005 13:37 ]