Jump to content

sps

Members
  • Posts

    16
  • Joined

  • Last visited

    Never

Profile Information

  • Gender
    Not Telling

sps's Achievements

Newbie

Newbie (1/5)

0

Reputation

  1. Personally I would use - $sql = "SELECT * FROM users WHERE username = '".$username."' AND password = '".$password.'" ORDER BY username ASC LIMIT 1;"; simply for readability. But your example with all single quotes - $sql = 'SELECT * FROM users WHERE username = \''.$username.'\' AND password = '\'.$password.'\' ORDER BY username ASC LIMIT 1;'; may have a tiny performance benefit. (As php doesn't have to evaluate single quoted strings for variables.) And again, for readability I would use the $username and $password variables as you have them at the sacrifice of the tiny bit of overhead required to assign a new variable. (It also makes it easier to add further checks (i.e. regex, etc.) on them in the future.) And yes, you would use %d for integers and %s for strings. (and %f for float, etc.) There should be a list in the php manual under sprintf that shows the different place holders. The reasoning behind using that being (AFAIK) that sprintf will throw an error if something other than that type is injected in that field. (Though for all strings it seems useless IMHO.)
  2. Use your first example and add 'LIMIT 1' to the end of the query. (After all, there can't be more than one username with that password in your setup, right?) That along with the escaping and single quote usage in your first example is fine for SELECT statements. Your second example appears to be partly from the php manual (as $product_name and $product_description don't fit your username/password variables.) The reason they do it that way in the manual for that example is to prevent SQL Injection on an INSERT statement. http://phpsec.org/projects/guide/3.html#3.2
  3. No, you were checking mime type which if the file was uploaded from an HTML form then "image/jpeg" would be the mime type, but flash doesn't do things that way apparently.
  4. HA, sorry, how about - if ((substr(basename($_FILES['Filedata']['name']),-4,4) == '.jpg' || substr(basename($_FILES['Filedata']['name']),-4,4) == '.gif' || substr(basename($_FILES['Filedata']['name']),-4,4) == '.png') && ($_FILES['Filedata']['size'] < 350000)) {
  5. Whoops, try - if ((substr(basename($_FILES['Filedata']['name'],-4)) == '.jpg' || substr(basename($_FILES['Filedata']['name'],-4)) == '.gif' || substr(basename($_FILES['Filedata']['name'],-4)) == '.png') && ($_FILES['Filedata']['size'] < 350000)) {
  6. Since you only allow .jpg .gif and .png in your flash file I would just try something like this - if ((substr(basename($_FILES['Filedata']['name'],-4) == '.jpg' || substr(basename($_FILES['Filedata']['name'],-4) == '.gif' || substr(basename($_FILES['Filedata']['name'],-4) == '.png') && ($_FILES['Filedata']['size'] < 350000)) { Note that all this does is make sure the last 4 characters of the file name are .jpg or .gif or .png, it can not verify that the data in a file named as such is actually a valid graphic. (i.e. you could rename a .exe file to .jpg and it would still upload.) But as MIME types can be faked anyway I don't see this as much of an issue (compared to the "image/jpeg" check). If you really want to verify that the data is a valid graphic you may want to open the files with GD functions and save them using GD functions, any error in that process would signal invalid data.
  7. My guess again is that the flash uploader is not setting the MIME type correctly (the "image/jpeg" part) Try changing - if (($_FILES['Filedata']['type'] == "image/jpeg") && ($_FILES['Filedata']['size'] < 350000)){ to just the size check - if ($_FILES['Filedata']['size'] < 350000){ If it works then we can at least narrow it down to a MIME type issue. Edit: It appears files uploaded with flash always have a MIME type of "application/octet-stream" (regardless of what type of file it is.) So that appears to be why your IF statement is failing. I would just use the size check in your IF statement, and check that the file extension is .jpg or .jpeg, etc. in PHP.
  8. What type of column is p_id? If it is not an INT then you need each item in your in() clause enclosed in quotes. If it is an INT column then it should work as written, does it give an error or just return no rows?
  9. You definitely want that if() line to be - if (($_FILES['Filedata']['type'] == "image/jpeg") && ($_FILES['Filedata']['size'] < 350000)){ (as the flash uploader names it as such, not "uploaded_file") Do you have access to the php error_log file? It may give you a clue. The print_r() won't help using the flash file as an uploader as it never redirects to that page for you to view it. You are saying it is allowing gif files to be uploaded even with the if statement in place? My guess would be that the flash uploader is not setting the mime type correctly then. If you only want to allow jpegs you might as well change - imageFile.browse([{description: "Image Files", extension: "*.jpg;*.gif;*.png"}]); to - imageFile.browse([{description: "Image Files", extension: "*.jpg"}]); in your action script. (Sill need to check it with PHP though.)
  10. Did you try the print_r($_FILES); after uploading a file or just by going to the upload.php page itself? It should have some info in it after a file upload. Your flash uploader won't show the print_r() data so it may be best to try with a simple HTML form for testing (or dump the $_FILE array to a flat log file so you can see what is going on.) And if ['Filedata'] works without the IF clause then that is what you need to use in the if clause, not ["uploaded_file"] (unless that is what the flash uploader is naming it.) Other than that discrepancy I don't see why it wouldn't work (maybe the flash uploader isn't setting the mime type correctly?)
  11. I am sure I am missing something, but where do you make the switch from $_FILES['Filedata'] (in your original script) to $_FILES["uploaded_file"] in your if() statement? Should these not match? Which name is the flash form posting to? What shows up when you do a print_r($_FILES); ?
  12. Edit : My apologies, didn't read the last line of your original post, made my response invalid.
  13. setcookie() has to come before ANY page output so if the beginning of your script really begins as typed, you need to move - to after the setcookie() calls.
  14. Did you put the session_cache_limiter('nocache'); between ob_start(); and session_start(); on your welcome.php file? (It must be before session_start() calls and I believe AFTER ob_start() calls.) If that doesn't work try removing your ob_start() calls and see what happens. If that still doesn't work try searching for different cache limiter directives, nocache should work in Safari if no other cache related headers are being sent first, but there may be other options you could use that I am not familiar with.
  15. Try placing - session_cache_limiter('nocache'); before your session_start() calls. This SHOULD send the proper headers so that neither proxy or browser caching will occur. If you need caching enabled then hopefully someone else can give you a more creative solution. Edit: You may want to try session_cache_limiter('must-revalidate'); too, as I remember having issues with IE and the nocache directive.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.