Is dit een logische volgorde?
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
if ( is_uploaded_file($_FILES['file']['tmp_name']) )
{
$this->create_image($_FILES['file']['tmp_name'], $new_thumb_path, 320, 180, ZEBRA_IMAGE_CROP_CENTER);
$this->create_image($_FILES['file']['tmp_name'], $new_photo_path, 640, 480, ZEBRA_IMAGE_CROP_CENTER);
if ($insert = $this->media->add_video($title, $description, $link, $file_name))
{
http_response_code(200);
echo 'Succes.';
}
}
{
$this->create_image($_FILES['file']['tmp_name'], $new_thumb_path, 320, 180, ZEBRA_IMAGE_CROP_CENTER);
$this->create_image($_FILES['file']['tmp_name'], $new_photo_path, 640, 480, ZEBRA_IMAGE_CROP_CENTER);
if ($insert = $this->media->add_video($title, $description, $link, $file_name))
{
http_response_code(200);
echo 'Succes.';
}
}
Nu is mijn vraag is dit wel de juiste benadering? Want als de foto wel word geupload naar de folder maar er gaat iets mis met de insert dan is de gehele query nutteloos en andersom het zelfde. Of zie ik het verkeerd. Hoe zouden jullie dit aanpakken?
En anders foto's verwijderen als er iets mis gaat. Dat moet toch al, want je kan niet garanderen dat na de eerste foto de tweede ook lukt.
Die is_uploaded_file() is nog een overblijfsel uit PHP 4, toen er nog geen $_FILES was.
Waar controleer je of het uberhaupt een afbeelding betreft?
Thomas van den Heuvel op 23/05/2018 10:40:43:
Waar controleer je of het uberhaupt een afbeelding betreft?
@Thomas. Hoe bedoel je Thomas. Kun je aangeven met een voorbeeld wat je bedoeld
Wat als iemand een PHP-file zou uploaden?
Gewijzigd op 23/05/2018 12:52:01 door Donald Boers
Daarom zou ik (en Thomas zou vast hetzelfde zeggen, denk ik) om getimagesize of FileInfo te gebruiken. Controleer ook ALTIJD op mime-types en het laatste deel van een extentie.
Nog mooier is om het wiel niet nogmaals uit te vinden, en een bestaande class te gebruiken. Ikzelf gebruik voor mijn uploadsysteem in mijn beheerbackend de UploadClass van Verot.net. Erg veelzijdig en makkelijk in gebruik. Vooral als je nog een PlUpload gebruikt.
Gewijzigd op 23/05/2018 13:02:32 door - Ariën -
Quote:
Nu is mijn vraag is dit wel de juiste benadering? Want als de foto wel word geupload naar de folder maar er gaat iets mis met de insert dan is de gehele query nutteloos en andersom het zelfde. Of zie ik het verkeerd. Hoe zouden jullie dit aanpakken?
Het is een goede zaak om je "zorgen" te maken en vraagtekens te plaatsen bij de betrouwbaarheid van informatie die wordt aangeleverd door anderen. Hierbij is het een "gezonde" houding om hier altijd (licht) paranoïde over te zijn (Do Not Trust User Data).
Ook is het zaak dat de informatie die wordt aangeleverd in de goede vorm wordt aangeleverd. Daartoe worden formuliergegevens meestal eerst gevalideerd, en daarna (na succesvolle validatie) verwerkt. Dit ook om te garanderen dat het proces voor verwerking goed verloopt want dat proces doet namelijk meestal aannames over de (vorm van) de input.
Als het zaak is dat er pas een record geïnsert wordt als er een afbeelding succesvol is geupload (en op de goede plek is gezet), insert dan pas een record nadat je hebt vastgesteld dat:
- de upload succesvol was
- het inderdaad een afbeelding betrof
- die de juiste afmetingen en grootte had
- waarbij het verplaatsen / hernoemen / resizen / whatever ook allemaal is gelukt en de afbeelding dus op zijn uiteindelijke bestemming in zijn uiteindelijke vorm staat
Het record is als het ware (of zou dit wellicht moeten zijn) een bevestiging / getuige van het slagen van alle bovengenoemde stappen.
En wat @Ben zegt: als alle informatie (afbeelding en anderszins) in één handeling wel of juist niet verwerkt zou moeten worden (zodat er geen onvolledige of ronduit niet kloppende informatie in je db komt te staan) zul je dus van database-transacties gebruik moeten maken.
Dit garandeert dat alle database-bewerkingen in zijn geheel worden doorgevoerd (als alles klopt) of in zijn geheel niet (als er iets niet klopt).
Gewijzigd op 23/05/2018 13:54:17 door Thomas van den Heuvel
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
// aangenomen dat bestand is gekozen en dan controleren
if ($_FILES['file']['error'] !== UPLOAD_ERR_OK) {
die("Upload foutgegaan " . $_FILES['file']['error']);
}
$info = getimagesize($_FILES['file']['tmp_name']);
if ($info === FALSE) {
die("Alleen images/afbeeldingen kunt u uploaden. Dit bestand is niet geldig");
}
if (($info[2] !== IMAGETYPE_GIF) && ($info[2] !== IMAGETYPE_JPEG) && ($info[2] !== IMAGETYPE_PNG)) {
die("Let op, bestand is geen gif/jpeg/png");
}
if ($_FILES['file']['error'] !== UPLOAD_ERR_OK) {
die("Upload foutgegaan " . $_FILES['file']['error']);
}
$info = getimagesize($_FILES['file']['tmp_name']);
if ($info === FALSE) {
die("Alleen images/afbeeldingen kunt u uploaden. Dit bestand is niet geldig");
}
if (($info[2] !== IMAGETYPE_GIF) && ($info[2] !== IMAGETYPE_JPEG) && ($info[2] !== IMAGETYPE_PNG)) {
die("Let op, bestand is geen gif/jpeg/png");
}
Gewijzigd op 23/05/2018 14:28:17 door Jan te Pas
denk ik de oplossing waar ik verder naar moet kijken
@Ben. Bedankt daarvoor.
@Jan te Pas. Bedankt voor deze informatie. Ga ik inderdaad even verder naar kijken
Quote:
De vraag was/is of de volgorde die ik voor ogen had in orde is.
Nou, wat gebeurt er als $this->create_image() mislukt? Wordt er dan een exception gegenereerd, en wordt de verwerking van het formulier dan gestaakt? Hier heeft dat ogenschijnlijk geen gevolgen (er worden geen return values geïnspecteerd?). De create_image() aanroepen worden uitgevoerd, en vervolgens komt daar altijd een handeling achteraan (wat doet $this->media_add_video() precies?). Zijn er daarnaast nog andere queries die uitgevoerd worden en dus eigenlijk ook gebundeld zouden moeten worden in een transactie?
Quote:
Jullie denken toch niet dat ik niet check op extensies of grote van het bestand?
Dat weet ik niet, kon het iig niet opmaken uit code/bovenstaand verhaal.
Zoals ik het zie wil je iets dat een combinatie van al het bovenstaande is: eerst controleer je of alles klopt, dan probeer je alles weg te schrijven, naar bestanden of database, waarbij je altijd een back-out strategie hebt waarbij je de toestand van voor het toevoegen herstelt als er onverhoopt toch iets misgaat zodat de data die je hebt (database, bestanden et cetera) gezond en onderling kloppend is en ook blijft.
Transacties zoals @Ben beschrijft en de controles van @Jan hierboven zijn middelen daartoe, maar wat voor oplossingen je hiervoor ook verzint, je moet een soort van achterliggend plan hebben wat er *in grote lijnen* moet gebeuren om je data kloppend te houden.
En dat plan is meestal ook in blokken opgedeeld, eerst heb je meestal een formulier validatie, dan heb je allerlei andere bewerkingen en controles en tot slot heb je nog een rits aan queries die in één batch worden uitgevoerd. Als er op enig moment tijdens zo'n blok iets misgaat vindt er een totale "rollback" plaats en wordt de gebruiker teruggestuurd naar het formulier met begrijpelijke foutmeldingen zodat deze foute invoer kan herstellen en alles opnieuw kan versturen.
Ik kan zo'n volgorde in het bovenstaande niet echt vaststellen.
Gewijzigd op 24/05/2018 00:26:59 door Thomas van den Heuvel