Jump to content

Pikachu2000

Staff Alumni
  • Posts

    11,369
  • Joined

  • Last visited

  • Days Won

    11

Everything posted by Pikachu2000

  1. $sql = "SELECT id, category, bilde, title FROM oppskrift_table WHERE category = 'Appetizers & Beverages' ORDER BY title ";
  2. The form field name= values look backwards to me. Just sayin' . . .
  3. Hahaha. Yeah, I'm around again. Probably not nearly as much as I used to be, but who knows? My poor Stars didn't do so well today . . .
  4. Look at the opening php tag for the require_once() in template.php. Notice anything missing?
  5. If you're saying you have bar stored in a variable without the double quotes and want to echo it with quotes: $foo = 'bar'; echo '"' . $foo . '"';
  6. The only validation you have is probably the Javascript for the form, which is pretty much useless as an actual validation method. Spambots and pretty much anyone who knows how to shut off Javascript in their browser can easily bypass it. All user input needs to be validated on the server side. Anything on the client side should be considered to be nothing more than a convenience (or inconvenience in some cases) for the user.
  7. No. You're over-complicating it to death. Just table.field is fine, backticks should never be needed with that syntax. Your initial problem was caused by one of the AS aliases: as out, not a table or field name. Really, your best course of action would be to simply forget about the backticks and use a different field alias; one that isn't a reserved word.
  8. I'm relatively certain you don't need backticks with this syntax: table.field, and if you did use them for whatever reason, it would be `table`.`field` rather than `table.field`
  9. All string type user data should be escaped before being allowed anywhere near a query string. mysql_real_escape_string or mysqli_real_escape_string, depending on whether you use mysql or mysqli extension functions.
  10. Kicken linked the manual page. Did you even bother to look at it?
  11. If phpinfo shows it as off you should be good to go. What are the current symptoms and updated code?
  12. With the code indented and formatted a bit better, it's much easier to see where these problems are: <?php if (isset($_GET['success']) && empty ($_GET['success'])) { echo'You\'ve been registered successfully! Please check your email to activate your account'; } else { if(empty($_POST)=== false && empty($errors) === true) { $register_data = array( 'username' =>$_POST['username]'], 'password' =>$_POST['password]'], 'first_name' =>$_POST['first_name'], 'last_name' =>$_POST['last_name]'], 'email' =>$_POST['email]'], 'email_code' =>md5($_POST['username']+ microtime()) ); register_user($register_data); header('Location: register.php? success'); exit(); } else { if (empty($errors) === false) { echo output_errors($errors); } } ?>
  13. EDIT: The same thing Jessica said follows, but in a long-winded format : ) Using the .= (concatenation) operator appends a value to an already initialized variable. The = (assignment) operator initializes the variable and assigns a value to it. Since register_globals was silently initializing variables with names that correspond to the form field names without your knowledge, your .= operation was concatenating the same value to it again. So to initialize and assign a value to a variable, use the = operator . . . And if you're able to do so, restart Apache so the changes to php.ini take effect immediately.
  14. And even though your syntax to assign the values from the $_POST array to the variables is wrong, in this case it's what actually exposed the fact that register_globals is on. If you don't have access to your php.ini file, contact your host and request that it be turned off. If they won't, find a new host.
  15. Turn off register_globals in your php.ini file. Why a host would have that enabled by default in 5.3 is beyond me.
  16. Have you taken care of this? It will never work until you do.
  17. My response wasn't aimed at you; I must have had the thread open before you submitted. But honestly, as far as I'm concerned since it can't, with certainty, prevent things from being submitted that shouldn't be submitted, it can't be considered validation. So I guess we'll have to agree to disagree on that point. Anyhow, I haven't seen you around in a while. Good to see you back.
  18. Your <select> field needs a name= attribute, which you would then use to get the value of the <option> from the $_POST array, validate it, and use that value in the delete query.
  19. Again, javascript is not validation. You must do validation on the server side. All javascript can be considered is a convenience to the user when properly implemented, or possibly a large annoyance when improperly implemented. Using htmlentities is fine to help prevent XSS, but you also need to add code server side to prevent submitting the form with required fields left empty and prevent email header injection. The problem is almost never caused by human users, but by spambots, and they don't pay attention to javascript at all.
  20. Your host should have a section in their FAQs about how to properly connect to the database server, but surely you don't want to connect with the http protocol like you're trying to do now.
  21. That's exactly my point. If it can be disabled by the user, it isn't validation at all.
×
×
  • 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.