Is dit een logische volgorde?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Donald Boers

Donald Boers

22/05/2018 23:13:18
Quote Anchor link
Ik heb een insert functie waarbij naast dat er gegevens naar de database worden geschreven er ook een foto wordt geupload. Ik gebruik JQUERY/AJAX om te beoordelen of alles naar wens verloopt. Nu heb ik op dit moment het volgende in de functie:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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.';                
    }
}

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?
 
PHP hulp

PHP hulp

22/11/2024 05:16:15
 
Ben van Velzen

Ben van Velzen

22/05/2018 23:23:48
Quote Anchor link
Transactie er omheen, rollback als het mislukt als je eerst de insert doet.
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.
 
Rob Doemaarwat

Rob Doemaarwat

22/05/2018 23:38:39
Quote Anchor link
Side-note: als je file toch al uit $_FILES komt, dan is het een uploaded file (en kan de gebruiker de tmp_name nooit "faken"), en is die is_uploaded_file() eigenlijk niet meer nodig (tenzij je d'r ergens daarvoor zo'n enorme puinhoop van hebt gemaakt dat je niet kunt garanderen dat $_FILES niet door een gebruiker kan worden aangepast, dan is het een handige check, maar dan moet je je wel even achter je oren gaan krabben mbt die puinhoop).

Die is_uploaded_file() is nog een overblijfsel uit PHP 4, toen er nog geen $_FILES was.
 
Thomas van den Heuvel

Thomas van den Heuvel

23/05/2018 10:40:43
Quote Anchor link
Waar controleer je of het uberhaupt een afbeelding betreft?
 
Donald Boers

Donald Boers

23/05/2018 12:26:59
Quote Anchor link
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
 
- Ariën  -
Beheerder

- Ariën -

23/05/2018 12:34:25
Quote Anchor link
Wat als iemand een PHP-file zou uploaden?
 
Donald Boers

Donald Boers

23/05/2018 12:50:56
Quote Anchor link
@- Ariën -. Omdat het hier een upload formulier betreft waar de eigenaar van de website de gegevens van een video insert/upload (titel, link, omschrijving, foto) Er is geen enkele reden voor deze persson om een PHP file up te loaden. Als jullie dit anders zouden doen kom dan even met een voorbeeld!
Gewijzigd op 23/05/2018 12:52:01 door Donald Boers
 
- Ariën  -
Beheerder

- Ariën -

23/05/2018 13:01:43
Quote Anchor link
Als iemand (als is het iemand die niet in de beheerbackend mag komen) een PHP-script kan uploaden, kan je de sjaak zijn. Volledige controle over je site is mogelijk, veiligheidsbarrières kunnen worden overruled, data kan uitlekken etc....

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 -
 
Thomas van den Heuvel

Thomas van den Heuvel

23/05/2018 13:50:39
Quote Anchor link
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
 
Jan te Pas

Jan te Pas

23/05/2018 14:27:25
Quote Anchor link
Onderstaand script controleert of het geuploade bestand daadwerkelijk een image is:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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");
}
Gewijzigd op 23/05/2018 14:28:17 door Jan te Pas
 
Donald Boers

Donald Boers

23/05/2018 22:07:05
Quote Anchor link
@- Ariën - en @Thomas De vraag is niet of het wel een foto is die wordt geupload 3n of deze wel aan de grote voldoet. De vraag was/is of de volgorde die ik voor ogen had in orde is. Jullie denken toch niet dat ik niet check op extensies of grote van het bestand? Om aan te tonen wat ik van plan was heb ik alleen dat gedeelte van de functie laten zien en als je goed kijkt zien jullie ook dat ik zebra image (image manipulatie) gebruik om te bepalen wat de grote van de images is die worden weggezet. Dus dan is inderdaad de oplossing van Ben
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
 
Thomas van den Heuvel

Thomas van den Heuvel

24/05/2018 00:18:47
Quote Anchor link
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
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.