[php] caching images

[Verwijderd]

Ik zit met een probleempje doordat mijn server allow_url_fopen niet aan wil zetten.

Ik ontvang een feed en vanuit die feed ontvang ik een url http://www.url.nl/getimage.php?parameters om een bepaald plaatjes op te halen.

Wanneer ik nu de copy functie of fopen functie gebruik krijg ik natuurlijk als resultaat 'false' doordat allow_url_fopen niet aanstaat.

Normaal gebruikte ik het commando copy om het plaatje naar een caching map te kopieren.
Vanuit die caching map werk ik dan met de <img src="" /> tag om het plaatje weer te geven.

Wanneer ik <img src="http://www.url.nl/getimage.php?parameters" gebruik dan werkt het ook alleen doordat ik redelijk tot veel items heb wordt mijn website enorm traag en is de andere partij waar de feed van is niet blij vanwege traffic.

Ik wil de plaatjes dus cachen alleen doordat die functie niet werkt zou ik op dit moment niet weten hoe ik dit het beste voor elkaar kan krijgen.

Wat ik weet via de andere partij is dat de getimage.php functie een mime type geeft middels een header() commando en vervolgens met readfile() het plaatje afdrukt.

Hoe kan ik dit nu het beste oplossen?

[OxiMoron]

Hopen dat cURL wel werkt en anders andere hosting zoeken.

[Verwijderd]

Top dank je wel

Heb nu een werkend script met CURL

[BCC]

OxiMoron schreef op woensdag 07 november 2007 @ 14:50:
Hopen dat cURL wel werkt en anders andere hosting zoeken.

Ik denk dat heel weinig fatsoenlijke hosters dat aan hebben staan, gezien de security hazards:
http://technosailor.com/l...nd-remote-file-execution/

[T-MOB]

Mocht cURL niet aan staan kun je ook nog zelf met fsockopen aan de slag. Zoiets werkt al vrij aardig:

PHP:

define('CRLF', "\r\n");
function getFile($host, $resource = '/') {
    $return = NULL;

    $fp = fsockopen($host, 80, $errno, $errstr, 30);
    if ($fp) {
        $headers = 'GET ' .$resource .' HTTP/1.1' .CRLF
                .  'Host: ' .$host .CRLF
                .  'Connection: Close' .CRLF .CRLF;

        //request
        fwrite($fp, $headers);

        //response starts with headers
        $head = TRUE;
        while (!feof($fp)) {
            $line = fgets($fp);

            //write content to return buffer
            if (!$head) {
                $return .= $line;
            }
            
            //end of HTTP headers
            if ($line == CRLF) { $head = FALSE; }
        } 
        fclose($fp);
    }
    return $return;
}

$ct = getFile('tweakers.net','/');
print_r($ct);

[FragFrog]

BCC schreef op woensdag 07 november 2007 @ 15:15:
Ik denk dat heel weinig fatsoenlijke hosters dat aan hebben staan, gezien de security hazards:
http://technosailor.com/l...nd-remote-file-execution/

Die hele "exploit" gaat er vanuit dat een hacker een kwaadwillend script aan kan passen op jou server. Als ik PHP files op jou server aan kan passen kan ik net zo goed het commando direct daarin plempen in plaats van moeilijk lopen doen en een veel groter risico lopen traceerbaar te zijn, dat hele artikel is dus vrij stompzinnig.

Ja, als jij iets doet als include($_GET['include_file']); gaat het mis en dat is ongetwijfeld de reden dat veel providers het uit hebben staan, maar dergelijke code is sowieso al te dom voor woorden (en de hoofdreden waarom ik geen phpMyAdmin meer gebruik trouwens, maar dat geheel terzijde).

Sowieso zie ik de relevantie met het topic of de post waar je op reageert niet, dit gaat om een bestand ophalen, niet een remote bestand uitvoeren. fopen en file etc zijn gewoon binary save (met een redelijk recente PHP versie anyway) dus zolang je bestanden die je ophaalt maar niet in een uitvoerbare directory zet of handmatig een niet-uitvoerbare extensie meegeeft kunnen die nevernooitniet uitgevoerd worden.

* FragFrog wordt een beetje moe van alle onzin die over security geschreven wordt

[djiwie]

Sowieso heb ik het idee dat allerlei PHP "exploits" die zogenaamd gevonden worden vooral komen door slecht programmeerwerk en niet door een flaw in PHP... Aandacht voor security is goed, maar dan wel op de juiste punten.

[BCC]

djiwie schreef op woensdag 07 november 2007 @ 23:59:
Sowieso heb ik het idee dat allerlei PHP "exploits" die zogenaamd gevonden worden vooral komen door slecht programmeerwerk en niet door een flaw in PHP... Aandacht voor security is goed, maar dan wel op de juiste punten.

Probleem is dat je als webhoster geen enkel zicht heb op al je klanten, dus daarom zullen de meeste het uit hebben staan. Het enige alternatief is namelijk alle code van je klanten waar dit in voorkomt controleren...

[FragFrog]

BCC schreef op donderdag 08 november 2007 @ 01:38:
[...]

Probleem is dat je als webhoster geen enkel zicht heb op al je klanten, dus daarom zullen de meeste het uit hebben staan. Het enige alternatief is namelijk alle code van je klanten waar dit in voorkomt controleren...

Natuurlijk, als hoster doe je dat, maar als je zelf een bak hebt staan of een virtual host hebt is het onzin om functionaliteit uit te zetten of niet te gebruiken 'omdat het onveilig is' - bijna geen enkele functie is onveilig as such, ze zijn alleen erg krachtig waardoor je ervoor moet zorgen dat je alle invoer controleert. Ergo, register_globals uit, query variabelen sanityzen en als je dynamisch functionaliteit kan aanmaken ervoor zorgen dat alleen functies uit een vooraf gedefinieerde lijst gebruikt kunnen worden. Je kan bijvoorbeeld prima iets als include($_GET['page'].php); gebruiken als je het maar bijvoorbeeld zo doet:

PHP:

$allowed      = array('index', 'foo', 'bar');
$_GET['page'] = in_array($_GET['page'], $allowed) ? $_GET['page'] : 'index';
include($_GET['page']);

Er zijn trouwens legio variaties op dit thema, een switch bijvoorbeeld werkt ook prima, zolang je maar een check doet. Maargoed, dit gaat wel heel erg hard offtopic, waarvoor mijn excuses

[ Voor 5% gewijzigd door FragFrog op 08-11-2007 19:34 ]