[PHP]Foto uploaden werkt lokaal wel, online niet altijd

zaterdag 15 december 2007 16:43

Doe een print_r($_FILES) en kijk eens wat daaruit komt. Met zo'n lap code kan niemand wat. In de documentatie kun je voor alle error-codes in de $_FILES superglobal precies de betekenis zien.

Met error_reporting(E_ALL | E_STRICT) zou je ook al wat meer foutmeldingen zien. Ik noem het ontbreken van isset en het overslaan van quotes bij $_GET[action].

Daarnaast zit er een veiligheidslek in je script: bovenin na het versturen van de location-header wordt de rest van je script gewoon uitgevoerd. De location-header wil bovendien de volledige url hebben, niet de relatieve.

[ Voor 26% gewijzigd door GlowMouse op 15-12-2007 16:43 ]

Acties:

console

Heb je wel schrijfrechten op de desbetreffende map waarin je de foto's uploaden?

zaterdag 15 december 2007 16:47

Acties:

zaterdag 15 december 2007 17:00

Topicstarter

ja heb rechten.

Ik ga meteen kijken mouse, en ik heb idd geen flauw idee over de veiligheid. Dankje

Met die error dingen krijg ik dit lokaal terug:

print_r:
Array ( [foto_bestand] => Array ( [name] => 8 juni 07 014.jpg [type] => image/jpeg [tmp_name] => C:\DOCUME~1\Kees\LOCALS~1\Temp\php71.tmp [error] => 0 [size] => 496780 ) )

error_reporting
Notice: Undefined index: submit in c:\phpdev\www\jp\admin\upload_foto.php on line 180

online komt hij niet eens op dat punt....dus even uitpluizen

[ Voor 66% gewijzigd door SoeperKees op 13-01-2008 14:24 ]

Acties:

zaterdag 15 december 2007 17:07

Ik neem toch even de tijd om commentaar op de rest van je script te geven.

Dit is de pagina in de handleiding die ik bedoelde. Je kunt het beste alles doorlezen, want er kloppen nog wat meer dingetjes niet. Je werkt bijvoorbeeld nergens met move_uploaded_file, en dat is wel de aangewezen methode. Dat het op andere manieren ook kan werken is meer geluk dan logica, met name bij shared hosting levert het anders problemen op.

Bij je INSERT-query kun je id, ik neem even aan dat het een auto_increment veld is, geheel weglaten ipv leeg invullen.
$datum, $tijd, $bericht en $categorie worden helemaal niet geëscaped voordat ze in de database verdwijnen, bij $naam gebeurt dit wel maar op de verkeerde manier (mysql_real_escape_string() is voor MySQL de enige juiste manier). Je kunt input het makkelijkste afhandelen met een eigen functie of klasse die je een keertje schrijft en altijd kunt hergebruiken. Daarbij check je eerst of magic_quotes_gpc aanstaat, en zoja kun je gelijk stripslashes gebruiken om risico op dubbele escaping te vermijden.
Je inputchecks kunnen sowieso nog een stuk beter, want als ik nu als datum of tijd 'asdf' opgeef (dat ze hidden zijn, betekent niet dat ik ze niet kan veranderen, zelfde geldt voor categorie), levert dat geen problemen op. Daarnaast loopt je script volledig de soep in als ik voor de grap een textfile ipv een plaatje upload. Door te kijken of getimagesize false teruggeeft, kun je dit weer makkelijk ondervangen.

Acties:

zaterdag 15 december 2007 17:22

Topicstarter

OK dankje, ik zal die even doorlezen.
En bedankt voor de rest van de tips

Acties:

zaterdag 15 december 2007 17:36

Je werkt bijvoorbeeld nergens met move_uploaded_file, en dat is wel de aangewezen methode. Dat het op andere manieren ook kan werken is meer geluk dan logica, met name bij shared hosting levert het anders problemen op.

Hij upload ook niet, hij doet een imagejpeg. Hoe wilde je anders images resizen en opslaan?

bij $naam gebeurt dit wel maar op de verkeerde manier (mysql_real_escape_string() is voor MySQL de enige juiste manier).

Dat is een beetje mierenneuken. Addslashes is goed genoeg, tenzij je een wel heel exotische karakterset gebruikt. Ben het geheel met je eens dat andere zaken ge-escaped moeten worden.

Acties:

zaterdag 15 december 2007 18:00

orf schreef op zaterdag 15 december 2007 @ 17:22:
[...]
Hij upload ook niet, hij doet een imagejpeg. Hoe wilde je anders images resizen en opslaan?
[...]

Via een tijdelijke directory waar je wel in mag komen. Zie ook de handleiding:

Note: move_uploaded_file() is both safe mode and open_basedir aware. However, restrictions are placed only on the destination path as to allow the moving of uploaded files in which filename may conflict with such restrictions. move_uploaded_file() ensures the safety of this operation by allowing only those files uploaded through PHP to be moved.

Dat is een beetje mierenneuken. Addslashes is goed genoeg, tenzij je een wel heel exotische karakterset gebruikt.

Waarom zou je het niet gelijk goed aanleren, in plaats van iedere keer dat je het gebruikt hopen dat het goed genoeg is?

Acties:

zaterdag 15 december 2007 19:08

Via een tijdelijke directory waar je wel in mag komen. Zie ook de handleiding:

Dus eerst moven naar een temp dir, dan uitlezen en een imagejpg gaan doen?!
Het is heel simpel, je hebt een resource waar je een afbeelding mee maakt. Die gemaakte - nieuwe - afbeelding kun je outputten of opslaan. Voor dat laatste heb je schrijfrechten nodig. Dat heeft niets te maken met move_uploaded_file. Je bent waarschijnlijk in de war met copy.

Waarom zou je het niet gelijk goed aanleren, in plaats van iedere keer dat je het gebruikt hopen dat het goed genoeg is?

Ik zeg ook niet dat het fout is, alleen mierenneuken. Kun je me één voorbeeld noemen waarmee addslashes een veiligheidsrisico vormt? Ik ken er wel één, maar die is in een productieomgeving zo goed als onmogelijk.

Acties:

zaterdag 15 december 2007 19:22

Topicstarter

Btw hoe kan het dat hij voor sommigen wel kiest om te uploaden en anderen weer niet?
Zodra ik zeg dat hij hem moet uploaden is hij wel bezig met uploaden, maar op een gegeven moment stopt hij er gewoon mee en niet meteen boem how.

Is er een soort timeout oid?

[ Voor 6% gewijzigd door SoeperKees op 15-12-2007 19:09 ]

Acties:

zaterdag 15 december 2007 19:29

Je doet totaal niet aan foutafhandeling. Misschien gebruikt het resizen te veel geheugen, misschien is de afbeelding progressive, of iets anders. Je kijkt niet of $_FILES gevuld is voordat je er dingen mee doet, je doet een getimagesize, zonder eerst te controleren of je daadwerkelijk met een image te maken hebt.

Het toverwoord is dus simpelweg debuggen. Toon of log errors na iedere functie die iets doet met je afbeelding.

[ Voor 11% gewijzigd door orf op 15-12-2007 19:24 ]

Acties:

zaterdag 15 december 2007 19:37

Topicstarter

Ik doe dat wel zoals ik al eerder poste, toen wel op mijn lokale server maar dit is nu online:

Maar ik moet inderdaad nog zien wat haar daarvoor doet, want hij komt dus niet altijd tot dat invoeren in de database toe.

Dat printen doe ik pas als het invoeren in de DB gedaan is.

Hieronder even een opsommingen van dingen

PHP:

1
2
3

print_r($_FILES);

Array ( [foto_bestand] => Array ( [name] => foto.jpgwtc.jpg [type] => image/jpeg [tmp_name] => /tmp/phpyWPDgj [error] => 0 [size] => 241136 ) )

kijken of het een foto is.

PHP:

$types = array ( "image/pjpeg", "image/jpeg", "image/gif", "image/png", "image/xpng" );

if(in_array($_FILES['foto_bestand']['type'] , $types))
{

[ Voor 5% gewijzigd door SoeperKees op 15-12-2007 19:31 ]

Acties:

zaterdag 15 december 2007 19:42

En de type kan net zo goed leeg zijn. Dat geeft de browser mee. Je moet serverside kijken of het een image is.

Acties:

zaterdag 15 december 2007 19:50

orf schreef op zaterdag 15 december 2007 @ 18:00:
Dus eerst moven naar een temp dir, dan uitlezen en een imagejpg gaan doen?!
Het is heel simpel, je hebt een resource waar je een afbeelding mee maakt. Die gemaakte - nieuwe - afbeelding kun je outputten of opslaan. Voor dat laatste heb je schrijfrechten nodig. Dat heeft niets te maken met move_uploaded_file. Je bent waarschijnlijk in de war met copy.

imagecreatefromjpeg/getimagesize kun je niet zomaar op $_FILES['foto_bestand']['tmp_name'] uitvoeren, omdat $_FILES['foto_bestand']['tmp_name'] in een directory kan staan waar je helemaal niet mag komen ivm open_basedir. Het is niet zonder reden dat er naast rename een aparte functie is die move_uploaded_file heet.

Ik zeg ook niet dat het fout is, alleen mierenneuken. Kun je me één voorbeeld noemen waarmee addslashes een veiligheidsrisico vormt? Ik ken er wel één, maar die is in een productieomgeving zo goed als onmogelijk.

Waarschijnlijk kennen we dezelfde met GBK.

SoeperKees schreef op zaterdag 15 december 2007 @ 19:08:
Btw hoe kan het dat hij voor sommigen wel kiest om te uploaden en anderen weer niet?
Zodra ik zeg dat hij hem moet uploaden is hij wel bezig met uploaden, maar op een gegeven moment stopt hij er gewoon mee en niet meteen boem how.

Dat kun je pas zeggen wanneer je ziet wat de inhoud is van $_FILES als het foutgaat. Wanneer het goedgaat, kun je daar geen informatie uit halen over een mogelijke fout. De output die je geeft verstrekt dus niets extra's (even aannemende dat het daar inderdaad goed ging, anders zit je fout niet in het uploaden).

Acties:

soap

diskoers.

Hoe zit het met de post_max_size en upload_max_filesize op de server?
Grote kans dat die anders zijn ingesteld als lokaal.
Kijk ook even of er een imagemagick module is geinstalleerd op de hosting (vaker wel dan niet); dan kun je hem hiermee eerst nog een keer converteren naar .jpg in de tmp directory naar een andere dir.

.

zaterdag 15 december 2007 19:56

Acties:

zaterdag 15 december 2007 20:15

Topicstarter

*

Mr.Zop schreef op zaterdag 15 december 2007 @ 19:50:
Hoe zit het met de post_max_size en upload_max_filesize op de server?
Grote kans dat die anders zijn ingesteld als lokaal.
Kijk ook even of er een imagemagick module is geinstalleerd op de hosting (vaker wel dan niet); dan kun je hem hiermee eerst nog een keer converteren naar .jpg in de tmp directory naar een andere dir.

die max sizes zijn 12b dus dat is het niet.

ok er gebeurd iets met, na de eerste imagecreateformjpeg,

PHP:

1 2	$image = imagecreatefromjpeg($fotosrc); $image_t = imagecreatefromjpeg($thumbnailsrc);

waardoor hij stopt....als ik daar iets wil laten tonen doet niets het...ook als ik die error_reporting(E_ALL | E_STRICT); doe zie ik niets

[ Voor 79% gewijzigd door SoeperKees op 15-12-2007 20:15 ]

Acties:

zaterdag 15 december 2007 20:23

SoeperKees schreef op zaterdag 15 december 2007 @ 19:56:
ok ik heb het nu zo om te kijken wat er met die _$FILES gebeurdt op verschillende punten:

Je wijzigt $_FILES nergens in je script, dus hij is overal hetzelfde. Snap je wel waarom je naar $_FILES moet kijken om de fout op te sporen of probeer je maar te doen wat hier gezegd wordt? Als je die eerder gegeven handleidingpagina doorleest, staat daar precies waar je allemaal rekening mee moet houden.

SoeperKees schreef op zaterdag 15 december 2007 @ 19:56:
ok er gebeurd iets met, na de eerste imagecreateformjpeg,
PHP:
1
2
$image = imagecreatefromjpeg($fotosrc);                                             
$image_t = imagecreatefromjpeg($thumbnailsrc);
waardoor hij stopt....als ik daar iets wil laten tonen doet niets het...ook als ik die error_reporting(E_ALL | E_STRICT); doe zie ik niets

Geen fout met uploaden dus. Hoe zit het met PHP's geheugengebruik (memory_limit)? Staat display_errors wel aan? Verschijnt er wat in de errorlogs? Kun je de foutmelding in de broncode wel terugzien?

[ Voor 38% gewijzigd door GlowMouse op 15-12-2007 20:17 ]

Acties: