phppup

At first glance I have two questions that come to mind. First, why are you using the query SELECT * (asterisk gives ALL values) if you want ONLY values for a specific user? Perhaps, SELECT item, next item, etc WHERE username = $username would be more defining. (You can research "php select where" for better understanding) Also, I don't see anywhere that you are specifying which user's information you want displayed. Maybe I missed something, but I hope this is helpful.

You're correct The explanation is confusing. But if you're trying to $_POST a specific time, you don't even need to bother with hiding it in HTML. Just create it as a variable in your PHP and insert it from there. There is A LOT of information of dates and time and their notations on the web. (The PHP manual and W3 sites are popular.)

I'm not the best resource on the block, but hopefully my experience can lead you in the right direction. From what I see, you're problem is in this line (which, btw, is doing exactly what you've designed it to do): You need to understand different concepts here. First, what the UPLOAD code is doing is to grab a bunch of images (after overcoming your first problem in the post), get their names, check their extension and eventually insert into the db. The catch is that it's grabbing the BUNCH and then going through this process FOR EACH; singularly. One by one, the BUNCH is being handled and reviewed and ultimately inserted into the db until the same process repeats for the next image in the bunch. Unless the image is rejected (ie: not a valid extension) it is written into the db on a new row. Then the loop goes back to the top for the next image. Second, your QUERY is inserting into a column called NAME. (Do you want the images to sit on each other's laps??? Of course not) if you truly want 3 images in one row (I wouldn't recommend it) then, at the very least, you would need to add fields that they could placed into; presumably name2 and name3. Then it would be up to you to modify the code to either UPDATE the row during loop2 and loop3 OR create a loop that manages 3 cycles before a single INSERT into the db. My suggestion would be to expand on what you've got and add fields that will help you regroup the three images later on (ie: username) assuming that's the reason you want then all in one row. Another question would be whether you can guarantee that nobody has more than 3 images to submit. But if you give each image is own row, and reference the row to an identifier (username) they can submit unlimitedly, and you will be able to reference then accordingly.

Changed my code slightly, but still not getting a successful result Does is_uploaded_file merely confirm that the path described is the same path used? Does getimagesize() serve any purpose beyond obtaining the MIME type? How do I re-create a TIFF file?

And I thought this was gonna be easy. LOL Is this a correct and effective use for security: Does getimagesize() serve any purpose beyond obtaining the MIME type? How do I re-create a TIFF file?

Thanks for clearing up a few things. Informative article, but didn't tell me how to prevent or handle an attack.

Is there a way to test it's functionality? Best way to ensure a TIFF is truly an image file?

I've got the is_uploaded_file in place. Let's assume a user attempts to upload several images and the second file is an empty NOT-uploaded file. Is it safe to CONTINUE my loop and rename the other files? Or is it more advisable to BREAK the loop immediately. Getting back to my initial thread, for file authentication, what is the equivalent to imagecreatefromjpeg for a TIFF file? What's the best way to handle them to minimize vulnerability?

Yes to both, huh? Interesting Got it. I suppose every pixel is individually represented. I wasn't sure if the inner workings of an image allowed for coding that might say "each corner is black" or "top half is blue." A few lines of code can create miles of resulting data, but I guess an image file is more literal in it's formatting. Although there must be a differentiation somewhere down the line. A camera can be set to take the same photo at different file size or different quality settings (what's the best combination when trying to budget a memory card?) And yet, the same photograph will produce a different file size when created in raw, jpg, or others. But that's probably a different chapter. LOL

I'll take a stab at this and say that a string becomes somewhat universal, but a file has stricter parameters that dictate it's handling. I would also suspect that while the average user accepts whatever file is afforded, there are probably pros and cons from an artistic/ photo/ graphic perspective and different image file types offer quality and access benefits. Would an enormous overload of memory generally be a maliciously inspired? Or simply a by-product of a particular image's content? Will resizing an image to a smaller file size automatically reduce it's maximum display size? It's color quality? Pixel saturation? I've not truly figured out what is being reduced and how the file is effected. So if an image file is stored in a db (not my intention, but I've seen many examples) is the file stored or is it translated into a string? Is the 'size' of a string generally smaller than the image file it supports?

Is there a "imagecreatefromfile" that's like imagecreatefromstring but works on files directly? No. Why not? Because as long as you know the type of file your chasing, you can select the appropriate imagecreatefrom... command! (Not gonna ask what happens if you use the wrong one... LoL) I was planning to resize images AFTER the upload. So image size is an unknown. With that in mind, I will try to maximize the allowable file size, but I'm guessing even that has limitations (regardless of my intentions for the new file)?

My confusion deepens. It seems as if imagecreate and imagecreatefromjpeg would be cousins, with ...from jpeg being more appropriate for validation. Am I correct in assuming that each extension needs is own ...createfromXYZ for accurate info? is_uploaded_file seems as if it's çlosing the barn after the horse has escaped. If it returns FALSE, but already has a tmpname, isn't the damage already underway? Does not working/moving the particular file "save the day"? So we're talking non-PHP coding to validate BEFORE upload (if I choose to be ultra user-friendly? I appreciate your help, but regarding getimagesuze, PHP.net has a CAUTIONARY note stating: Thus, my confusion escalates.

Secret doing some reading too educate myself, I am now more confused than before. LoL Trying to understand the most effective method to verify that an image is truly what is claimed. But the differences between using imagecreate, imagecreatefromjpeg, and is_uploaded_file are not easily noticed. Likewise, I read that it is best to check the image BEFORE uploading. But isn't the image already uploaded when submitted (although not yet moved or renamed)?

On a somewhat related issue, I've seen a lot of 'ideas' floated "on the internet" and was wondering about this: In this snippet, does PHP move the JavaScript code for client side accessibility? Or does this example add an additional burden to the server by transferring JS requirements to a server side function?

While working with some PHP (contained within the same webpage) it occurred to me that using JavaScript to evaluate a form submission could alleviate server traffic; it seemed like a good idea that if the form was incomplete the JS could terminate the form and the PHP would never be run. As a preliminary step, i adapted this code My expectation was that when BTN was clicked, the ALERT would fire, and RETURN false would prevent other processes from running (similar to a DIE() in PHP). Instead, the ALERT was triggered, but my PHP error/confirm msgs followed. Rather than leave the validation to PHP, i thought I'd ask for some insight here. Thanks.

Thanks. After some thought, I kinda realized that the starting point coincided with the submittal click. I guess it was too obvious to see initially. LOL In playing a bit, I did find that the GIF vanishes of its own, but I thought it was a flaw of some sort, so thanks for the extra info.

Thanks for the explanation. That would so seem to make sense. So back to the question: how do I access the beginning and end of this gap (in order to add a loading GIF? [If I'm understand correctly, if I select IMG62, and then IMG01, and then IMG23, my end result (while named sequentially) will be mismatched because of the order they were selected]

I suppose one advantage to having a slow internet connection is that it allows me to see potential issues from a unique perspective. With that in mind, I've noticed that selecting images to upload is nearly instantaneous, regardless of size or quantity. However, these factors become enormous after clicking the upload button. There seems to be a gap between the clicking of the button and the actual start of the upload process. (Is the server actually organizing the files and preparing the selected files in the array?) The question is, how do I access the beginning and end of this gap (in order to add a loading GIF? Essentially, the page is already loaded. It's the file processing/compilation that I'm trying to intercept (or piggy-back). Also, can I control which files are uploaded first, second, etc.? I know I can change file names, but can I control the order of the actual upload. Ex: uploading IMG01, IMG23, IMG62. Desired renaming my01, my02, my03, respectively. I've tried beginning my PHP script with: if(!empty(natcasesort($_FILES['files']['name']))) But the actual uploading seems to be random.

As mentioned, it's a hold-over of an old habit (although my database will probably be restructured next. LOL) Still, the double quotes were the only choice that didn't cause an error message. How do I get the variable in there? Or is it even worthwhile?

After deciding to venture into the realm of prepared statements, I have this line in my script Everything was working fine. I reviewed my code to adjust it to my old habits, and realized that I had hardcoded the TABLE NAME rather than using a variable. I updated my code to and results from my SELECT statement vanished. Is the use of a variable for a table's name outdated? Even possible??

Got it. (should names be case sensative) But AJAX is client side, so sanitizing is still highly recommended within PHP for the server side, right? On a related note, I've seen sanitizing examples that trim or remove HTML characters. Shouldn't an entry with such problems simply be rejected rather than repaired? Are the PHP sanitizing filters reliable on their own (to replace all the code that was required in the past)?

Thanks. Any other basic tutorial links would be helpful too. While developing my script, I noticed that the username is NOT case sensative. (There is NO string-to-lowercase in my code, yet it is acting as if it exists) Did I miss a step in my database or table? Should username disallow case differences (which would limit the number of potential combinations)? Passwords come to mind too, of course.

Day 2: making progress thanks to all I've learned here, but could REALLY use a link that would explain (in simplified terms) how to use AJAX in creating username availability. Thanks everyone.

Ahhhh, now it's starting to make sense (I think). So either way, that piece of code needs to exist (if not too send, then to receive)? As a tangent, given two scripts to accomplish the same task, is AJAX any better or worse than a JSON ?

I'll try that. But do I remove the Or redirect it with a $this (of some sort?