Jacques1

The whole approach doesn't make a lot of sense. So you generate random combinations over and over again in the hopes that you eventually get a unique combination? Why not just shuffle the three arrays and then combine the elements one by one? shuffle().

PHP doesn't like it when you override a method with different parameters in a subclass.

Who says multiplying the sum always gives you 3 digits? That may be true if you only deal with a specific set of input numbers (which one?), but it's obviously not the case for the generic algorithm. Just take the input "9999999999999". That gives you the sum 117. Multipliying the result with 9 yields 1053 which has four digits.

What are you doing there, RyanCain97? You store the password as plaintext? And then you put it into the session so that all precious passwords end up in unprotected files in the temporary folder? And then you restrict the password to alphanumerics? And this is all for the admin accounts? WTF?

You have to define html_escape() yourself. For example: function html_escape($input, $encoding) { return htmlspecialchars($input, ENT_QUOTES, $encoding); }

If you're bound to the old MySQL extension, then you have to use mysql_real_escape_string(). There's no alternative. You should go with PDO instead of MySQLi. The problem of MySQLi is that it's cumbersome as hell. And of course it's again a MySQL-specific extension which doesn't work with any other database system. PDO is a universal database interface which is compatible with all mainstream systems (PostgreSQL, MySQL, Oracle etc.) and generally provides much more comfort. There's just one pitfall: Prepared statements are disabled by default. To enable them, you have to explicitly set the PDO::ATTR_EMULATE_PREPARES option to false.

“Making the user input safe” is a rather vague requirement. Safe in what sense? The mysql_real_escape_string() function and htmlspecialchars() also have absolutely nothing to do with each other. I assume you want to pass a PHP value to a MySQL query while preventing SQL injection attacks. Yes, you can use mysql_real_escape_string() for that. It works perfectly fine if you know what you're doing: You never forget to escape a value. You wrap all values in quotes. You do not mess with the character encoding of the database connection. Unfortunately, this is easier said than done. A lot of PHP programmers screw up at least one of those aspects, which is why still so many application suffer from SQL injection vulnerabilities. And let's not forget that all mysql_* functions are obsolete since more than 10 years and will be removed in one of the next PHP releases. Prepared statements are a much more robust approach, because they actually solve the underlying problem. SQL injections happen when the input values change the query. This is impossible with prepared statements, because they strictly separate the input from the query itself. No matter which input you pass to the statement, it's always just a harmless value. So do use prepared statements. mysql_real_escape_string() was the approach of the 90s, now it's time to enter the 21st century.

MySQL has a DATE type for exactly that purpose.

CP-1252 and UTF-8 work the same way for ASCII characters, so you only have to convert the files which contain non-ASCII characters. It's probably enough to open the website in your browser and do a quick check for broken characters. In the Apache configuration or an .htaccess file. Just google for it or check the manual. Preferably, yes. But it won't say that unless you add the charset attribute to the Content-Type header. Yes. But since CSS files usually only contain ASCII characters (except maybe for comments), it makes no difference.

No, you get the encoding which you've set in your editor.

Sometimes it's a good idea to actually read the code before you hand out “advice”. This script essentially turns the server into an open mail relay: Anybody can send any mail to any address (by injecting their own headers). If the spam mafia finds this, the server IP will be blacklisted in no time, and I'm sure your web hoster won't find that very funny. Do not use the mail() function. This is a low-level function for experts who need to manually assemble the raw message and know exactly what they're doing. It is not for simply sending out an e-mail. If that's your goal, you need a mailer library like PHPMailer. You also can't just drop any user input into the e-mail body. You need to escape the values first. Otherwise, people will use this to inject all kinds of nasty JavaScript code.

First the things which (hopefully) everybody agrees on: Put all your PHP code before the HTML markup. Do not mix PHP and HTML, or you'll end up with an unreadable mess of spaghetti code. Put all your JavaScript and CSS into external files. Avoid inline scripts and styles under all circumstances, because those again lead to spaghetti code and prevent the use of effective security tools like Content Security Policy. Where exactly your script elements should be placed is somewhat controversial. Some people say that putting them right before the closing <body> tag will yield the best performance, some say they belong into the head element (possibly with an async or defer attribute for performance). Personally, I always put them into the head, because I think scripts are meta data.

getimagesize() finfo_file()

This implementation is actually incorrect. You somehow forgot about the “right to left” part, even if you've mentioned it in the original question. And when you try to extract the last digit, for some reason you assume that $totalFinal always has exactly three digits. It's important that “doubling every second digit” refers to the direction from right to left. So if the input is “123”, then you'd double 1 and 3 (all even indexes). If the input is “1234”, then you'd double 2 and 4 (all odd indexes). What you do instead is always double all odd indexes. This only works if the input has an even length. <?php $input = '7992739871'; $sum = 0; for ($i = 0; $i < strlen($input); $i++) { $digit = $input[$i]; /* * If the input length is even, we need to double all digits with an odd * index. If the input length is odd, we need to double all digits with an * even index. In other words, we double those digits where the remainder * of $i ÷ 2 is different from the remainder of strlen($input) ÷ 2. */ if ($i % 2 != strlen($input) % 2) { $digit *= 2; // Instead of calculating the sum of the digits, you can just subtract 9. if ($digit > 9) $digit -= 9; } $sum += $digit; } echo $sum; Then you multiply by 9 and get the last digit. The easiest way to get the last digit is to calculate the remainder of the division by 10: $checkdigit = ($sum * 9) % 10;

Why use arrays? How does this help? Simply add the digits in one loop with an if statement. The logic works like this: Loop through the digits from left to right (or right to left, it doesn't matter). If the total number of digits is even, double all digits with an even index (the first index is 0 as usual). If the total number of digits is odd, double all digits with an odd index. If doubling makes the number two-digit, subtract 9. Add the resulting number to a sum.

Using XHTML is not wrong, but I don't see the point. Unless you have a specific reason for why you need it, just go with plain HTML. There are a lot of great new features in HTML5, and you can still use XHTML syntax if you like. What I mean is that the <meta> tag itself as it stands in the HTML source code must be ASCII-encoded. This is automatically the case for UTF-8, because UTF-8 is a superset of ASCII. The browser doesn't know your PHP code. It only sees the resulting HTML document. You forgot the character encoding. But, yes, that's one way of setting the HTTP header. You can also do it with the webserver itself.

Before you jump to the technical details, I think the concept itself needs a reality check. Do you honestly believe that anybody on the Internet will wait 7 days for you to unban their IP address? I don't think so. Chances are they're back in 7 seconds with a new IP. I mean, even the dumbest script kiddie knows how to use a proxy, use ToR or simply reset their router. At the same time there's a huge risk of blocking legitimate users just because they happen to share their IP address with somebody else. If you hit a big proxy or VPN, you'll lock out hundreds or thousands of people who haven't done anything. Is your site so incredibly popular that you can live with that? I understand why programmers like IP bans: They're easy, they're cheap, and they give you the illusion of “doing something”. But I fear they solve no problems while creating new ones. I'm sure there's a better approach. What are you trying to do? Is this a public chat where you want to block certain participants? Then I'd use a cookie-like mechanism. Of course you shouldn't use actual cookies, because those are a bit too obvious. But if you search for Evercookie, you'll find a lot of more creative techniques. Another interesting concept is the hellban: Instead of actually blocking the user, you just ignore their messages. So while they believe they're still taking part in the discussion, they cannot be seen by anybody. Of course no technique is perfect. Anybody with a decent level of knowledge can circumvent any ban. What you can and should do, however, is keep the average troll busy without locking out half of the world's population.

Well, “all browsers” is a very broad term. Let's say: all modern mainstream browsers. I'm sure somewhere there's an obscure web client which doesn't understand UTF-8. But all browsers you'll encounter on a standard website do, and UTF-8 is in fact the official recommendation of the W3C. Note that you should also declare the encoding in a Content-Type header. Using a meta element usually leads to the expected result, but it's somewhat paradox: The browser has to understand the document so that it can get the information which is necessary to understand the document. This only works under certain circumstances: The meta element itself must be ASCII-encoded, and it must be within the first 1,024 bytes of the document. There are no such issues with the Content-Type header. Actually, the meta element should only be used as a backup in case the user views the document offline (in which case the HTTP headers are not available). Why do you use text/xml as the content type, by the way? The font is yet another story. Not all fonts actually include all 100,000 Unicode characters, so using a very exotic character and a very exotic font can theoretically lead to problems. But this isn't gonna happen for a simple curly quote. So if we leave aside all the obscure edge cases, then, yes, you can safely use any character you want.

He did.

Those are two different problems. The reason why double quotes must be escaped in some contexts is because they (obviously) have a special meaning in HTML. A literal double quote within a double-quoted attribute is ambiguous, because it could either be a literal character or an attribute delimiter. The HTML parser cannot handle this. However, there's no such ambiguity within the content of an element or within a single-quoted attribute, so in those cases, you can safely use a literal double quote. Whether or not you can use literal curly quotes within your document is an entirely unrelated issue. The problem is this: An HTML document by itself is just a sequence of bytes. If the browser should map those bytes to actual characters, then it must know how to do that. By far the best solution is to actually tell the browser which encoding you've used. This is done with the charset attribute in the Content-Type header and/or a meta element within the document itself. If you explicitly specify the encoding, then you can safely use any character from the underlying character set (as long as it doesn't have a special meaning in HTML, of course). You do not have to encode the characters with HTML entities, and you shouldn't. If you do not specify the encoding, then it's a very different story. The browser has to fall back on its default encoding which is probably something like ISO 8859-1 or Windows-1252. Now the only literal characters you can safely use are those from the ASCII set. A literal curly quote will almost certainly be misinterpreted. What you can do, however, is use HTML entities to represent Unicode characters within ASCII. This will also yield the right characters. But it does come at a price: The resulting document is much bigger (the “ entity takes 7 bytes, the same character in UTF-8 just 3), and it's much more effort on your part, because you have to encode every non-ASCII character. So do declare the encoding, and do use literal curly quotes.

It's a self-inflicted SQL injection, if you will. You can't just drop some URL parameter into a query string. If you're lucky, the script will simply crash due to a syntax error (which is what just happened). If you're less lucky, then people will actively exploit this bug and manipulate the query. They'll be able to fetch arbitrary data or even take over the entire server. People have actually pointed this mistake in your previous threads, but for some reason you've decided to try it again. What are you waiting for? An actual attack against your server? You need to at least escape and quote dynamic values before you insert them into a query. This is the absolute minimum. If you want proper code, then it's time to throw away those mysql_* functions and switch to PDO. The 90s are over.

If you want wishy-washy talk and a fake smile, programming is not for you. Go to Facebook or something.

So you're a PHP newbie, yet you know exactly that my way of debugging code is completely wrong and doesn't help? Fascinating. I've been using PHP for quite a while now, and I can assure you that the internal PHP functions don't just silently break. When there's a problem, there's almost certainly an error message. For example, running your code with incorret settings yields those two error messages: This tells you exactly what is wrong and what you need to do to fix the problem. Even if you don't know how to interpret the messages, this is extremely valuable information for the people trying to help you. Now, as long as we're dealing with simple problems, we may sometimes be able to guess the issue even if we have absolutely no information. That's what ginerjm did: He tried the code, did some research and eventually came up with an intelligent guess. That's OK, and it appearently worked out this time. But guessing is always the last resort. It's what you do when the person on the other end is simply too stupid (or technically incompetent) to give you the relevant information. You are neither stupid nor technically incompetent. You've written this piece of code, so you are definitely smart enough to describe the problem. Please do. It will save everybody a lot of time, and you'll benefit from a better answer. Do you now see what I mean? -

You somehow assume that addition takes precedence over string concatenation, but that's not the case. They have equal precedence and are evaluated from left to right. It's generally a bad idea to rely on the internal precedence of operators (except maybe for obvious cases like addition and multiplication). Use parentheses.

Checking the status of a registered member is obviously different from checking the status of a guest. For registered members, the “only” challenge is to notice when they're no longer active. For guests, you also run into the typical problems like unreliable IP addresses, unreliable cookies etc. Personally, I don't try to track guests, because it's a lot of trouble for very little relevant information. To check the status of a registered user, you usually want a combination of JavaScript and plain HTTP: Every n seconds, JavaScript sends a “heartbeat” to the server via Ajax. If the last heartbeat is older than n seconds, then the user has appearently left the site. Note that JavaScript may or may not be active, so it's not enough to rely on this feature. The log-in and every subsequent request update a timestamp. This gives you the last actual activity, but it also serves as a backup in case JavaScript is turned off. When the user explicitly logs out, they're obviously no longer active.