i need to mimic how an upload form work. i need to store a file into database and uploads the $_FILES into our folders. The problem every bit of code of the models and the form itself is based on legacy code. I don't have the the gut to strip all code and start over. I prefer to let it be
So, my goal is how to uplaod file without use the previous form and then only serialize/unserialize an object consist of filename and url. while the file itself have been story via copy function and not uploads form.
The only critical part of the $_FILES array for any particular request is the ...['tmp_name'] portion, since that points to where PHP saved the uploaded file. Save a copy of a $_FILES that's set up the way you want to test (with however many files you want), then manually change the tmp_name to point to actual files on your server, rather than the random garbage names that PHP autoassigns to uploads, and you could be able to reuse a copy of the data as many times as you want, as long as your scripts don't move/delete/munge the files you're pointing at.
So, something like:
$_FILES['file1']['tmp_name'] = '/path/to/file/to/test/with';
$_FILES['file2']['tmp_name'] = '/some/other/path/or/file/for/testing';
$savedfiles = serialize($_FILES);
and then you can stick a
$_FILES = unserialize($savedfiles);
wherever it's appropriate for testing your app.
Yes, it is possible to serialize $_FILES array;
$upload = serialize($_FILES["file"]);
If your code is dependent on the contents of the $_FILES variable then yes, assigning to it (whether the contents are from a serialised version in a database or wherever) should have the expected behaviour.
Generally speaking, contriving a small test is a much better way of finding out if something will work for your particular situation than asking people on the internet to speculate.
Related
When I am trying to access the uploaded file by using $_POST then I didn't get any info but if I use $_FILES the I will get all uploaded file related stuff.
Why we can't use $_POST instead of $_FILES?
This is a language design decision which was made by the creators of PHP long ago. You could ask the creator of PHP Rasmus Lerdorf (https://en.wikipedia.org/wiki/Rasmus_Lerdorf).
However there are some good reasons I can think about to seperate $_POST and $_FILES.
From the docs:
The global $_FILES will contain all the uploaded file information. [...]
Files will, by default be stored in the server's default temporary
directory, unless another location has been given with the
upload_tmp_dir directive in php.ini. The server's default directory
can be changed by setting the environment variable TMPDIR in the
environment in which PHP runs. Setting it using putenv() from within a
PHP script will not work. This environment variable can also be used
to make sure that other operations are working on uploaded files, as
well.
The $_FILES array contains info like name, type, size, temporary name, error information, temporary location and so on. So for a file a lot of information is required and it has seperate data stored in some temporary place.
The $_POST array just contains submitted text strings basically. Therefore my guess it that the design decision was made just because it is useful to have this variables clearly seperated.
I don't know which way is better to use about uploading and saving a file in my local server.
for example I see someone that INSERT image's link in the mysql field, I'm confused right now...
I want to upload some files and show that in other situation...
what's the best and secure way to perform that?
Store all the images in a folder called photos for example. Then, save an index of the file in your database assigning it an index number and other information. Save the file in the photos folder, renaming it [index_number].jpg, or whatever extension is needed. For example, if I upload the file coolpic.jpg, it will be assigned an index number of 2845. The file itself is saved in photos/2845.jpg.
Saving in Database may make some problems like as DB performance decrease (as result of reading and writing big files), DB crashes (as a result of delete of edits of rows fields), backup problems (because of huge dump file, some problems when table needs to be repaired.
also read file from mySQL will be delivered by Apache again.
I suggest you use of normal path with rewrite mode (virtual url)
Dont use img link.. its not necessary and all it does is just making you DB larger.
You shoud store just "picture.jpg"
and in documents use <img src="images/'.$row['image'].'">
Even better, you can create a function for it (displaying pictures).
Like
function DImage($image)
{
//you can do miracles here like checking images types, if is file and so on, padding, even adding divs and vspaces..
$output = '<img src="imagesfolder/'.$image.'">';
return $output;
}
so latter all you have to do is..
echo DImage($row['image']);
PS: if you ask about $_POST & $_FILE uploading, of course.. it is impossible for you to maintain images, names and updates I'm sure..
Alright, so a little preface: I've been working on adding drag and drop file uploading to the course management system called Moodle (specifically 2.0.1). This version of Moodle uses the YUI3 framework and uploads the form data with the file to be uploaded and the save-as name through an io-upload-iframe. The file is stored in the super global $_FILES until the filesystem is sent the relevant data on where to store it permanently.
The trouble I'm having is that instead of using YUI3's drag and drop features (Which, from a cursory look at their website is not the kind of drag and drop I need anyways) I'm using the native HTML5 drag and drop code. This seems to work in most major browsers (I haven't had the time to test much, and it's outside the scope of this project). The trouble I'm having is that this design of DND immediately gives you a file from the Event object in javascript. I could send this file object off to wherever I want, but the filesystem is only designed to handle variables temporarily stored in the $_FILES variable. I've not been able to find any easy way of getting this file stored there, unfortunately. I could to an HTTP request of various forms (either one of YUI3's special Y.io() requests or an XHR), but this requires a lot of duplicated code from the original source code.
Anybody have some suggestions?
Hard to tell what your problem is. But whatever your server or filesystem is, it has nothing to do with the temporarity of the $_FILES array.
When you receive the DND event, and YUI subsequently sends the file, then you will receive some data either in $_FILES or in $_POST. If so, just use move_uploaded_file or file_put_contents and store it elsewhere.
Assign that moved file a md5() hash as name, and have that returned as file identifier for your AJAX-DND upload request.
You can then use that hash id in your Javascript code, and refer to the already uploaded image file by this reference. Should your app initiate a normal form request after the drag'n'dropping, then you just include the collected image reference ids. And thus your server-side code can associate it again.
You could even reconstruct the $_FILES array if you want to:
foreach ((array)$_POST["prev_image_ids"] as $md5) {
$md5 = basename($md5);
$_FILES["image"][] = array(
"tmp_name" => $fn="./already-uploaded/$md5",
"size" => filesize($fn), "type"=>"image/whatever",
"name" => "unknown.jpg", "error"=>UPLOAD_ERR_OK,
); // you could store away those original attributes too
}
I'm generating a unique filename for uploaded files with the following code
$date = date( 'U' );
$user = $_SERVER[REMOTE_ADDR];
$filename = md5($date.$user);
The problem is that I want to use this filename again later on in the script, but if the script takes a second to run, I'm going to get a different filename the second time I try to use this variable.
For instance, I'm using an upload/resize/save image upload script. The first operation of the script is to copy and save the resized image, which I use a date function to assign a unique name to. Then the script processses the save and saves the whole upload, and assigns it a name. At the end of the script ($thumb and $full are the variables), I need to insert into a MySQL database, the filenames I used when i saved the uploads.
Problem is, sometimes on large images it takes more than a second (or during the process, the seconds change) resulting in a different filename being put into the database than is what the file is actually saved under.
Is this just not a good idea to use this method of naming?
AFAIK it's a great way to name the files, although I would check file_exists() and maybe tack on a random number.
You need to store that filename in a variable and reference it again later, instead of relying on the algorithm each time. This could be stored in the user $_SESSION, a cookie, a GET variable, etc between pageloads.
Hope that helps
Just want add that php has a function to create identifiers: uniqid. You can also prefix the identifier with a string (date maybe?).
Always validate your user's input, and the server headers!
I would recommend storing the file name in the session (as per AI). If you store it in one of the other variables, it is more likely for the end user to be able to attack the system through it. MD5 of user concatenated with rand() would be a nice way to get a long list of unique values. Just using rand() would probably have a higher percentage of conflicts.
I am not sure about the process that you are following for uploading files, but another way to handle file uploads is with PHP's built in handlers. You can upload the file and then use the "secure" methods for pulling uploaded files out of the temporary space. (the temporary space in this instance can be safely located outside of the open base dir directive to prevent tampering). is_uploaded_file() and move_uploaded_file() from: http://php.net/manual/en/features.file-upload.post-method.php example 2 might handle the problem you are encountering.
Definitely check for an existing file in that location if you are choosing a filename on the fly. If user input is allowed in any way shape or form, validate and filter the argument to make sure it is safe. Also, if the storage folder is web accessible, make sure you munge the name and probably the extension as well. You do not want someone to be able to upload code and then be able to execute it. That officially leads to BAD activities.
I just discovered that PHP has a built-in function for this, called tempnam. It even avoids race conditions. See http://php.net/manual/en/function.tempnam.php.
Why not to use
$filename = md5(rand());
This will be pretty much unique in every case. And if you find that $filename already exists you can just call it again.
Not a good idea using ID dependent on time – if you upload two images at the same time, the later one can overwrite the earlier. You should look at function such as uniqid(). However, if this upload/resize/save script is meant to be "single-user", then this is not such a big problem.
To the problem itself. If I were you, I would just save the computed filename to some variable a use the variable from that point. Computing already computed is waste of time. And when uploading some really big images, or more images at once, script can take even 20 seconds. You cannot depend on fact that you'll make everything you want in one second.
I am in the middle of making a script to upload files via php. What I would like to know, is how to display the files already uploaded, and when clicking on them open them for download. Should I store the names and path in a database, or just list the conents of a directory with php?
Check out handling file uploads in PHP. A few points:
Ideally you want to allow the user to upload multiple files at the same time. Just create extra file inputs dynamically with Javascript for this;
When you get an upload, make sure you check that it is an upload with is_uploaded_file;
Use move_uploaded_file() to copy the file to wherever you're going to store it;
Don't rely on what the client tells you the MIME type is;
Sending them back to the client can be done trivially with a PHP script but you need to know the right MIME type;
Try and verify that what you get is what you expect (eg if it is a PDF file use a library to verify that it is), particularly if you use the file for anything or send it to anyone else; and
I would recommend you store the file name of the file from the client's computer and display that to them regardless of what you store it as. The user is just more likely to recognise this than anything else.
Storing paths in the database might be okay, depending on your specific application, but consider storing the filenames in the database and construct your paths to those files in PHP in a single place. That way, if you end up moving all uploaded files later, there is only one place in your code you need to change path generation, and you can avoid doing a large amount of data transformation on your "path" field in the database.
For example, for the file 1234.txt, you might store it in:
/your_web_directory/uploaded_files/1/2/3/1234.txt
You can use a configuration file or if you prefer, a global somewhere to define the path where your uploads are stored (/your web directory/uploaded files/) and then split characters from the filename (in the database) to figure out which subdirectory the file actually resides in.
As for displaying your files, you can simply load your list of files from the database and use a path-generating function to get download paths for each one based on their filenames. If you want to paginate the list of files, try using something like START 0, LIMIT 50; in mySQL. Just pass in a new start number with each successive page of upload results.
maybe you should use files, in this sense:
myfile.txt
My Uploaded File||my_upload_dir/my_uploaded_file.pdf
Other Uploaded File||my_upload_dir/other_uploaded.html
and go through them like this:
<?php
$file = "myfile.txt";
$lines = file($file);
$files = array();
for($i=0;$i<=count($lines)-1;$i++) {
$parts = explode($lines[$i]);
$name = parts[0];
$filename = parts[1];
$files[$i][0] = $name;
$files[$i][1] = $filename;
}
print_r($files);
?>
hope this helps. :)
What I always did (past tense, I haven't written an upload script for ages) is, I'd link up an upload script (any upload script) to a simple database.
This offers some advantages;
You do not offer your users direct insight to your file system (what if there is a leak in your 'browse'-script and you expose your whole harddrive?
You can store extra information and meta-data in an easy and efficient way
You can actually query for files / meta-data instead of just looping through all the files
You can enable a 'safe-delete', where you delete the row, but keep the file (for example)
You can enable logging way more easily
Showing files in pages is easier
You can 'mask' files. Using a database enables you to store a 'masked' filename, and a 'real' filename.
Obviously, there are some disadvantages as well;
It is a little harder to migrate, since your file system and database have to be in sync
If an operation fails (on one of both ends) you have either a 'corrupt' database or file system
As mentioned before (but we can not mention enough, I'm afraid); _Keep your uploading safe!_
The MIME type / extension issue is one that is going on for ages.. I think most of the web is solid nowadays, but there used to be a time when developers would check either MIME type or extension, but never both (why bother?). This resulted in websites being very, very leaky.
If not written properly, upload scripts are big hole in your security. A great example of that is a website I 'hacked' a while back (on their request, of course). They supported the upload of images to a photoalbum, but they only checked on file extension. So I uploaded a GIF, with a directory scanner inside. This allowed me to scan through their whole system (since it wasn't a dedicated server; I could see a little more then that).
Hope I helped ;)