On Fri, 21 Mar 2003, Geoff Howard wrote: > >Is it? With in-memory upload you can get to OutOfMemory exceptions and > >potentially corrupt cocoon instance. With file uploads, you can create > >100Mb file systems which you can fill up but you won't disturb > >functionality of the server. I don't see how in-memory uploads are more > >secure; I see them as *less* secure. > > Well, in combination with the max-upload-size parameter (or whatever it's > called) I felt that better. If I can cause the request to ignore multipart > files bigger than xMB, that seems to mitigate the risk. But that's worth > some discussion. My worry with autosaving all files is 1) I can purposely > fill up your hard drive, given time. 2) Could a user more clever than I > create a POST request that would cause a file to be placed somewhere other > than the upload dir?
>From my experience with PHP, here's how it works: You have a PHP script that a form posts a file to. During the execution of the script, you have access to an object which represents the uploaded file. The object also contains the name of the file on the client machine, the mime/type, the actual size of the file uploaded, and the temporary name of the file as it is stored on the server. The uploaded file only exists on the filesystem for the duration of the script, and if you want to actually save it, you need to move the temp file into a directory. As soon as the script is done executing, PHP automatically removes the temporary file. This seems to work out just fine, and I haven't seen any bad security problems with it so far. For further inspiration, check out [1] Tony [1] http://www.php.net/manual/en/features.file-upload.php
