scootstah

You don't have to change anything on your INSERT query to use foreign keys. Is your query not working?

It is, but you can then install a Linux distro and a LAMP stack. That's how I do it. I just have my old PC on the floor with no mouse/kb or monitor attached running Ubuntu server. That way I can work on my desktop or laptop and don't have to sync up.

It is, but you can then install a Linux distro and a LAMP stack.

A single database query to fetch the user with the saved user ID shouldn't be a big deal. If you don't want to do that on every page load you could look into caching with something like memcached or APC, but I don't think that is really necessary.

Why not copy/paste the code between those tags into the minifier, and then copy/paste it back afterwards?

Shouldn't PDO::quote be adding the quotes? It only escapes any existing quotes, doesn't add them =) From the manual: Also I just tested it and it does in fact add the quotes, at least for MySQL.

Shouldn't PDO::quote be adding the quotes?

MySQLi supports transactions as well. However, the error you are getting implies that $DB is not a PDO object.

The pattern would be: /[a-z0-9\s]+/i However, is that really what you want to do? What about punctuation?

Initially I thought this was for private messages, but now I see it is for friend requests. Is there any sort of restrictions on what users any other user can add as a friend, or can any user add any user as a friend? If there is no restrictions, all you need to do is make sure that the requested user exists and that they are not already friends. If there is restrictions, you can validate that accordingly. Either way, you know the requested member ID - that's all you care about. It is irrelevant if the member ID is different than it was when you originally displayed the form, because your code will handle it the same way. Like I said, the user would have to purposefully and manually tamper with the form data in order for that ID to change. Whether or not you end up with the same member ID after submitting the form as you did when the form was displayed makes no difference.

I'm inclined to disagree. An MSSQL database - or any database for that matter - doesn't have to reside on the same server as the web server. SQL Server is a typical example where the database often resides elsewhere. Therefore, someone can gain access remotely should they get hold of the credentials. I believe in that case you could set it up to only allow certain connections, like your server. I might be wrong though.

But it doesn't matter. All you need to check is that the user has permission to send the message to the user that was sent with the form. Barring CSRF attacks, the user would have to tamper with the form themselves. If they already have permission to send the message to the person they tampered the form to send it to, then what difference does it make? You are simply making sure they can't tamper with the form to send a message to someone that they can't normally send one to.

Yes.

Holy shit. That sounds stressful.

All of those companies defined their respective industries. It's just a matter of riding out the trend. Wait for the next super awesome technology and take the opportunity. It is unlikely any random person will strike gold and rival Google or Facebook anytime soon.

A row has to exist in the emails table before you can create a row in the friend_emails table.

What is the error?

$type is a constant, and constants do not use quotes. $char is a string. As far as data types, I believe you'll want to use int for $type and string for $char.

Run the string: <b>this is bold</b> through the function. If you get: <b>this is bold</b> then it works. If you get: this is bold then it doesn't work.

Are you ignoring us on purpose?

Hmm. The first problem I see is that array_map isn't going to work for multi-dimensional arrays. Also, the error handling is unnecessary here - if it doesn't match expected data type just ignore it. Here is my take: function entities($input) { if (is_array($input)) { $clean = array(); foreach($input as $key => $val) { $clean[$key] = entities($val); } return $clean; } return htmlentities($input, ENT_QUOTES); }

Well, you still ought to pick an encoding (UTF8 is pretty standard) and make sure everything is the one you choose. It's not particularly difficult and is beneficial in the long run. That is an excellent idea!! Care to share how you'd do that? Probably with recursion. Check if your input is an array and then loop through it and re-call the function from within itself. This way you can easily traverse through multi-dimensional arrays without any extra effort. Other developers have used some variation of the "html entities" name to solve the same problem. Ultimately you are still using the htmlentities() function, but just wrapping it up first. It is converting symbols and such to their HTML entities. You can see a list of them here (excuse the w3schools link, their HTML entities charts happen to be good references). Essentially you are preventing XSS attacks by removing your users' ability to add markup to any dynamic content. < and > tags will be changed to their entities - < and > respectively.

Looks fine to me. You might want to also specify an encoding as a third parameter for the htmlentities() function (probably UTF8). If it were me, I would add support for arrays - so that you can pass an associative array to the function and get back a sanitized associative array. This way you don't have to run each key manually. Also, if I may be nitpicky, your function name doesn't accurately describe what the function does - since you're technically not escaping anything but rather converting it.

It's still not perfect enough. Let's jazz it up a little: System::output()->println(new String("Hello World")); Now PHP can be cool like Java!

The parent row has to exist first.