[PHP] INPUT Type=File: Hoe inhoud onthouden?

[Wolf3D]

Ik ben bezig met een formulier waarbij verschillende gegevens ingevoerd kunnen worden, alsmede 3 afbeeldingen. Na een druk op de submit knop worden alle gegevens gecontrolleerd. Indien er velden niet correct zijn ingevuld wordt het formulier weergegeven met alle ingevulde waarden, en bovenin de foutmeldingen.

Nu komt het probleem: Als de gebruiker afbeeldingen geselecteerd heeft, een verplicht veld leeglaat en op submit klikt, dan gaat hij terug naar het ingevulde formulier. Alleen de geselecteerde afbeeldingen in het <input type=file>-veld zijn weg. Bij ieder foutje dat hij maakt moeten de te uploaden afbeeldingen dus weer opnieuw allemaal opgezocht worden.

Na enig onderzoek ben ik er achter dat de value van dit veld niet onthouden kan worden en weer automatisch ingevuld kan worden. Logisch, want het zou een behoorlijk lek zijn.

Maar hoe zorg ik ervoor dat de gebruiker dan niet iedere keer de velden opnieuw hoeft in te vullen?

Zelf zat ik eraan te denken te afbeeldingen meteen op te slaan zodra er op submit is geklikt, maar .. als de gebruiker na een eerste submit, kiest om toch maar niet verder te gaan en zijn browser af te sluiten, blijven de plaatjes staan... en moet ik weer een ander script schrijven die om de zoveel tijd controleerd of afbeeldingen weg kunnen of niet.

Allemaal erg onhandig .. vind ik. Maar, wat is dan wel de beste (en meest professionele) manier?

Een vergelijkbaar voorbeeld van een website waar de bestanden bij een fout iedere keer opnieuw opgezocht moeten worden is http://www.aanbodpagina.nl/place.asp

[Gerco]

Helaas, een input type=file kun je niet zetten met script of HTML. Die is daartegen beveiligd, had ik ook eens last van op mn werk.

[NMe]

Je kan ervoor kiezen om je formulier te checken voordat je het verzendt (met behulp van Javascript), maar zoals Gerco al zegt, file inputs kun je niet automatisch vullen. Dat zou best een bijveiligingsrisico opleveren anders.

[Wolfboy]

Ik zou boven je file input veld gewoon een regeltje zetten waar staat dat bestand ..... geupload is en dus niet overnieuw geupload hoeft te worden, maar dan zal je die dus wel in een aparte map moeten bewaren.

[Gerco]

Inderdaad:

JavaScript:

fileinput.value = "c:\belangrijkbestand.doc";
form.submit();

Rinse & repeat voor interessante resultaten. Daarom kan het dus niet (en dat is nu net waar wij het ongeveer voor wilden gebruiken, meerdere files in 1 dir uploaden als de user er 1 had geselecteerd).

[Wolf3D]

Ja, dat is inderdaad duidelijk, dat met het <input type=file>-veld weinig gedaan kan worden. En terecht.

Het checken van het formulier met javascript is geen optie, aangezien het een wat geavanceerdere check is, en ik het netter vind met php.

Probleem met het direct uploaden van de afbeeldingen is .. dat het volgens mij dan een zootje wordt.
Een map vol met afbeeldingen die wel upgeload zijn, maar nooit gebruikt worden, omdat de gebruiker halverwege is gestopt ......

[NMe]

Wolf3D schreef op donderdag 14 juli 2005 @ 17:16:
Het checken van het formulier met javascript is geen optie, aangezien het een wat geavanceerdere check is, en ik het netter vind met php.

Check dan die dingen die met Javascript kunnen met Javascript, en de rest met PHP. De dingen die je met Javascript al controleert moet je toch ook nog eens met PHP controleren (user input nooit zomaar vertrouwen). Dat voorkomt in elk geval een paar gevallen waarin dit voor kan komen.

Probleem met het direct uploaden van de afbeeldingen is .. dat het volgens mij dan een zootje wordt.
Een map vol met afbeeldingen die wel upgeload zijn, maar nooit gebruikt worden, omdat de gebruiker halverwege is gestopt ......

Cronjob maken die elke 24 uur die map afgaat en alle files ouder dan een uur verwijdert? Stelt niet zoveel voor hoor.

[Nvidiot]

Een temp mapje maken en die eens in de zoveel tijd leegmikken. Als de submit goed gegaan is, bestand verplaatsen van de temp map naar de eigenlijke doel map

[Wolf3D]

Ja, een cronjob elke 24 uur die de temp-map leeggooit en verplaatsen van de files bij een goede submit is misschien de beste oplossing dan.

Zo vaak zal het eigenlijk ook niet gebeuren dat een gebruiker een plaatje selecteerd en upload en vervolgens toch maar stopt....

Okee! Duidelijk! Dat wordt m dan! Bedankt!

[Wolf3D]

Het systeem zoals hierboven beschreven, werkt! Tenminste .. tot vandaag.

Tot nu toe voerde ik het script om de thumbdir leeg te gooien nog handmatig uit en hiervan heb ik vandaag een cronjob gemaakt. Die elke 2 uur de dir leeggooit.
Maar nu krijg ik opeens allemaal Permission Denied-berichten......

Cronjobs hebben toch niet OOK weer een eigen UID toch?

[moto-moi]

cronjobs hebben het UID van de user waarvan de cronjob is.

[Wolf3D]

Euhm ... en dat is ...?
Ik maak een cronjob via CPANEL aan.
Ik maak de te verwijderen bestanden via PHP aan. Bestanden die users kunnen uploaden.
Die 2 UID's zullen dus niet hetzelfde zijn dan..... en dan is het dus nooit mogelijk om via een cronjob bestanden die via php zijn upgeload te verwijderen.... toch?

[moto-moi]

Nou, je maakt de crontab aan voor een bepaalde user, en die user z'n rechtenset wordt gebruikt bij het draaien van de crontab.

Dus als je files die door apache zijn neergezet wilt verwijderen, zul je de user waaronder apache bekend is bij je systeem dat moeten laten doen, vaak is dat de user 'apache' of 'web' o.i.d.
Dan kun je eenvouding als root 'crontab -e apache' doen, en dan pas je de crontab van die user aan.
Maar dat heeft bar weinig met programmeren te maken, meer met Non-Windows Operating Systems

[Grijze Vos]

Ik gok dat hij geen root access heeft.
Kun je de bestanden niet chmodden zodra ze binnenkomen?

[Verwijderd]

Misschien een idee om de plaatjes als stream in de sessie op te slaan? Als de sessie verloopt (gebruiker doet niets meer) dan wordt de sessie na verloop van tijd toch automatisch verwijderd. Doet de gebruiker er wel wat mee dan hoef je ze maar uit je sessie te trekken.

[Wolf3D]

Klopt, heb ik inderdaad niet.

Je bedoeld de thumnails chmodden? En dan op 777 ofzo? Lost dat het probleem op .. en brengt dat niet weer nieuwe problemen op het gebied van beveiliging met zich mee?

@Bushwoelie: Wordt php daar niet vrij traag van? De limiet van een plaatje staat op 2 MB .. dus .. theoretisch gezien kan het gebeuren dat een sessievar 6MB (3 afbeeldingen max) aan data meedraagt ... per gebruiker die op dat moment bezig is. Lijkt me niet handig toch?

[ Voor 41% gewijzigd door Wolf3D op 22-07-2005 16:12 ]

[Verwijderd]

Je kan hem er weer uit halen als je er verder iets mee doet. Ik denk eerlijk gezegd dat het wel meevalt, maar het hangt natuurlijk ook van het aantal gebruikers en de gebruikte hardware af.

Wat eventueel ook nog een mogelijkheid is, is dat je inderdaad alle bestanden onder dezelfde directory zet (evt in subdirs), en bijv 4x per dag alle bestanden in die map ouder dan pakweg een paar uur weer verwijderd.

[Wolf3D]

Tja, het systeem moet voorbereid zijn op grote aantallen users. Dat is iig wel de bedoeling.
Dus het meesturen van bestanden in sessievars lijkt me niet fijn voor het geheugen van de server, welke overigens niet van mijzelf is maar bij een hostingprovider staat.

Dat laatste wat je zei snap ik waarschijnlijk niet helemaal. Dit is toch weer hetzelfde als een cronjob ... als ik deze 4x per dag de bestanden laat verwijderen? En dan heb ik het probleem met de rechten weer ...

[T-MOB]

Je kunt ook een PHP-script maken dat de directory afzoekt naar afbeeldingen ouder dan zeg 2 uur. Dat script kun je eens in de 24 uur aanroepen met een cronjob, of je voert het gewoon eens in de 1000 hits op je pagina uit. Het is niet heel netjes, maar je hebt in elk geval de juiste rechten als je de bestanden door PHP/Apache laat verwijderen

[Wolf3D]

Met een cronjob gaat het (tot nu toe) dus niet lukken. (zie boven)
Het eens in de zoveel tijd een script laten uitvoeren vind ik idd niet echt netjes. Het zou nu tijdelijk wel ff een oplossing zijn, maar op de lange termijn wordt het een zooitje als ik het zo ga aanpakken, denk ik.....
Zijn er geen andere oplossingen om de rechten gelijk te krijgen. Dus dat OF de cronjob wordt uitgevoerd onder het UID dat PHP ook gebruikt, of dat de bestanden worden geupload onder de UID van de gebruiker.

Via de FTP-functies van PHP kan ik deze rechten wel gelijk trekken .. heb ik ontdekt .. maar .. om iedere keer een ftp-verbinding te openen lijkt me ook niet bevordelijk voor snelheid en veiligheid van het systeem...

[js303]

als je geen gebruik van cronjobs kunt maken, en je gaat ervanuit dat de temp-map met files toch niet erg vol zal worden, kan je dan niet ergens in een php script- bijv. in het upload-script - de functie maken die de temp-files checkt en alles wat erin staat en ouder is dan een bep. datum eruit mieteren (unlinken)? dan heb je wel even server-load bij het uploaden, maar je gaat er toch niet vanuit dat die temp-map stampvol zit..?

zelfs dan zou je het nog kunnen minimaliseren, door bijv. in een db bij te houden wanneer voor het laatst de temp-folder geleegd is, en in de aanroep van die verwijder-functie dit te checken en al dan niet het legen uit te voeren.. en dan zodra deze functie uitgevoerd wordt, aan het einde een update op de db doen met de timestamp van dat moment.

[ Voor 38% gewijzigd door js303 op 25-07-2005 10:11 ]

[Wolf3D]

Ja, dit is inderdaad een mogelijkheid. Maar ik vraag me af of het niet een rommel wordt als ik het op deze manier aan ga pakken.
Misschien beter om toch maar het hele systeem om te gooien en over te gaan op de veel minder nette manier: Javascript. En een submit pas toestaan als alles goed ingevuld is....
Tot nu toe pakken alle websites, die ik kon vinden en hetzelfde doen als wat ik wil, het aan met javascript. Behalve de website die ik ook in mijn startpost noemde...

[js303]

ja maar zoals al eerder gezegd, kan je nooit zeker weten of de post/get data die je in php krijgt aangeleverd, zuiver is. dus je zal - als je het veilig wilt hebben - toch ook in php moeten checken of bepaalde velden wel/niet ingevuld zijn, of ze te lang zijn en/of ongeldige data bevatten.

om het jezelf wat makkelijker te maken, zou je het check-gedeelte in php een stuk grover kunnen laten, bijv. als een bepaald veld niet (juist) gezet is gewoon afkappen en een exit("incorrect form / field data") aanroepen, aangezien je het toch netjes in javascript afvangt (alert('u heeft het ...veld niet ingevuld!')) en theoretisch mensen dit kwaadwillig moeten bypassen om op het check-gedeelte in php te stuiten... alle 'normale' gebruikers zullen bij evt. incorrect invullen nette waarschuwingen via js krijgen en hun wijzigingen kunnen maken alvorens de boel gepost wordt, terwijl het hack-tuig dat om de javascript heen probeert te komen dan ook lomp tegengehouden wordt door php.

[ Voor 72% gewijzigd door js303 op 25-07-2005 11:43 ]

[Wolf3D]

Ja, inderdaad. De PHP-controle zit er toch al in, dus die laat ik gewoon staan, zodat ik inderdaad zeker weet dat alles goed binnenkomt. Hier zet ik dan nog een extra Javascript-beveiligingsschil voor.

Het is wel erg dubbelop .. en de kans dat foutmeldingen gemixed worden. (Foutmelding 1 (bijv. veld leeg) via een alert en Foutmelding 2 (bijv. onjuiste mime-type) een foutmelding dmv een tekst-waarschuwing.). Maar dit lijkt me toch de beste oplossing inderdaad..