KevinM1

Not only that, but the validation side of it is entirely dependent on the context of what the site considers to be valid data. There's no way to standardize that as the needs for each site varies. Site A allows user names to contain special characters. Site B allows user names to contain special characters except ' and `. Site C doesn't allow user names to contain any special characters. There are a few standard things to do, depending on circumstance - always escaping strings before using them in a db query, always running text through htmlentities before outputting it to the screen, etc. - but there's no good way to take into account all possibilities (are you going to take uploaded files into account? if so, good luck...), and certainly not in a way that would be useful for the web, where response time is critical. It's far more efficient to simply write validation and sanitation for the specific needs of a particular site.

The problem is that you keep resetting the total to 20. You need to check if a total exists. If there is NOT a pre-existing total, set it to 20. Else, simply use what you have for the calculation.

What are you actually trying to accomplish? Because, aside from the visible <br> that's before t1.sh, it looks like it's working properly.

I'm afraid I'm not all that familiar with Java. Have you tried asking on an Android forum, or on Stack Overflow? Because there's nothing in your PHP that jumps out at me. Your code produces an array that looks like: [agencyname1, agencyname2, agencyname3, ..., agencynamen] Which is a legit JSON array. So the problem has to be in your decode function, somewhere.

What is it actually outputting?

JSON arrays also start with [. Curly braces (e.g., {}) are used to denote JSON objects. See: http://www.json.org/ How are you trying to decode this?

Caveat: a parent's variables (and functions) are available to their children if they're marked as public or protected. Private members aren't shared.

Maybe if you explained how soldiers are represented in your code you'd get a better answer. $soldier = 100 doesn't convey any meaning.

I'm looking at getting PhpStorm (and RubyMine, made by the same company). Thoughts? Impressions?

Too true. Programming is hardly ever yes/no, right/wrong, black/white. It's usually about finding a balance between: What works What's easy to read/understand (in a professional environment, you're all but guaranteed to be working with others on the same code) What's efficient

It's still rendered by PHP. Remember: PHP is what is generating the HTML sent to the browser. Anything, even a blank space, that's rendered before you attempt to redirect will result in that error. The key is to organize your script(s) properly: ALL PHP processing (store results in variables and determine if you need to redirect) | | | | V HTML output Meshing chunks of PHP with HTML is a bad way to go. At most, you should only have if/else-conditionals and loops embedded in your HTML. All other processing should be done beforehand.

Okay, here's a canned example: // database connection and table selection code goes here if (isset($_POST['submit'])) { if (!empty($_POST['email'])) { $email = filter_var($_POST['email'], FILTER_VALIDATE_EMAIL); } else { $email = false; } if ($email) { $email = mysql_real_esape_string($email); $query = "SELECT * FROM table WHERE email = '$email'"; $result = mysql_query($query); if (mysql_num_rows($result) == 1) { $row = mysql_fetch_assoc($result); echo "User name: " . $row['username']; } else { echo "ERROR: multiple accounts have the same email address."; } } else { echo "ERROR: invalid email."; } }

That's not escaping. http://en.wikipedia.org/wiki/Escape_character#Programming_and_data_formats Essentially, escaping modifies the behavior of certain characters. Why is that important? Well, in SQL, certain characters do certain things, and if they were just blindly inserted into a query, they could have disastrous results. Classic example: anything' OR 'x'='x Looks pretty innocent, but let's say that was entered into a form, and you have the following query: SELECT * FROM table WHERE email = '$input' The actual executed query would look like: SELECT * FROM table WHERE email ='anything' OR 'x'='x'; Since 'x'='x' always results in true, every record will be retrieved. It seems like an innocent mistake, but these kinds of attacks - SQL Injection attacks - are very dangerous. They can grant an attacker access to the entire database, and all the sensitive information within. An SQL Injection is what brought the PSN down earlier this year. So, how does escaping thwart injection? It turns anything' OR 'x'='x into anything\' OR \'x\'=\'x which turns the example query into SELECT * FROM table WHERE email = 'anything\' OR \'x\'=\'x' which is a value not found in the database. Now, why can't you simply use addslashes to escape string data? Addslashes() does not escape all possible characters. Therefore, it's always best to use the escape method relevant to the kind of database you're using. --- $dbh is an object. PDO stands for PHP Data Objects. If you're not familiar with object oriented programming, use MySQLi instead.

Well, for starters, you'd need to validate $added_by. Is it only supposed to contain letters? Letters and numbers? Any special characters? See, that's what we mean when we say that form validation and security is dependent on context. What are you requiring the value to be? The one sure thing I can say is that you want to pass $added_by into mysqli_real_escape_string before using it in your db query. Like I said before, all text that's being used by any query needs to be properly escaped. Since you're not using prepared statements in your example, you need to do it manually with that function.

You can't invoke a method unless one of two things happens: 1. You instantiate a new object of the type you want to use, i.e.: $obj = new DatabaseInsert(); $obj -> ArticleInsert($table, $fields, $values); 2. You declare the method as static: class DatabaseInsert { public static function ArticleInsert($table, $fields, $values) { // blah } } // ... DatabaseInsert::ArticleInsert($table, $fields, $values); That said, what you're attempting to do isn't very OOP. You're not gaining anything by simply stuffing your function in a class. Grouping functions by theme is not OOP, regardless of whether or not you use classes and objects.

Since you're trying to access a $toppings variable that wasn't assigned to, or otherwise initialized, it looks like you have register_globals on, which is a very big security risk. In fact, register_globals is turned off by default in PHP5+ and only exists for backwards compatibility. I also believe that register_globals will be removed from PHP altogether relatively soon. Also, you don't need to cast $_POST['toppings'] as an array. PHP already turned it into an array because you named each check box toppings[] in your HTML form. All that said, what you want to do is fairly trivial: $implodedToppings = ''; foreach($_POST['toppings'] as $value) { $implodedToppings .= '$value, '; } $implodedToppings = substr($implodedToppings, 0, -2); // get rid of the extra comma and space at the end echo $implodedToppings;

Awesome stuff, guys. Thanks!

I'm going to be an uncle sometime in June. I'd like to buy my niece or nephew some geeky baby clothing, but don't know where to look. All I've found so far is a onesie that says "I just boldly went." Any ideas?

htmlentities with ENT_QUOTES and UTF-8.

This entire post is hilarious. If your server is compromised, your data is compromised. You cannot assume that only your document root will be victimized. PFMaBiSmAd said everything necessary in Reply #3. And, really, there's no functional difference between keeping a password in a plaintext file and using PHP's file access methods to access it, or storing it as a variable and include-ing it. What matters is that the password is either placed outside of the web root, if possible, or protected by an .htaccess file if not.

Exactly. Never, ever, ever trust anything coming in from $_GET or $_POST. Always run it through whatever processes you need in order to verify that the data coming in is legit and useful. This is especially important if that incoming data is going to be used as part of a database query or is going to be displayed on a user's screen. But, aside from general advice, we can't say much more because it all depends on what your individual needs are for whatever project you're working on. There's only a handful of "Always do this/never do this" rules: Always escape string (text) data that will be used in a database query. Never use addslashes for this. Instead, always use the escape method that comes with the database you're using (like mysql_real_escape_string) OR, even better, use prepared statements with MySQLi or PDO, as prepared statements automatically escape strings. That will help stop injection attacks. For output Always run user-supplied data through a function that will swap tags for their HTML entity counterparts. htmlentities with ENT_QUOTES and UTF-8 should do the trick. It's easiest to do this right before echoing the data. That will help stop XSS attacks. Always validate incoming data. Expecting a number? Run it through is_int to make sure. Expecting an email address? Run it through filter_var with the email flag. Want data to conform to a certain unique format? Use regular expressions and the preg functions.

Sanitizing is generally inputs-only because one would assume you'd only want to store and/or display clean/valid/verified data. There's nothing stopping you from using sanitizing functions in other instances, it's just an ass backwards way of doing things.

Screw that. Just wire some nand gates together.

Also, slight digression, but never use the 'global' keyword. Use a function's argument list to pass in all parameters.

Look at the JavaScript....