Jacques1

No. The (hexadecimal) hash of the submitted token is exactly the same as the stored hash. It's also effectively unique, so no further identifiers are required. The workflow is like this: generating: raw_token := secure_rand(16) mail(hex_encode(raw_token)) database_store(hash(raw_token)) validating: raw_token := hex_decode(url_param("token")) database_search(hash(raw_token))

unserialize()

I send the original token (in some human-readable format), not the hash. The hash is used to protect the token from being stolen from the database, just like a password hash (after all, the token is equivalent to a password). When the user submits the human-readable token, I transform it back into the original binary form, calculate the hash and check if that hash is stored in the database.

Casting an SQL integer into a PHP integer can lead to truncation, because MySQL can go up to 64 bit unsigned, whereas PHP is limited to either 32 bit signed or 64 bit signed (depending on the platform). A better (but still hacky) approach would be to check if the string only contains decimal digits. However, a prepared statement is indeed the way to go: $class_ids = [10, 20, 30, 40]; $cooking_classes_stmt = $database_connection->prepare(' SELECT class_id -- select *specific* columns, not just "*" FROM cooking_classes WHERE class_id IN ('.implode(',', array_fill(0, count($class_ids), '?')).') '); $stmt_params = []; $stmt_params[] = str_repeat('i', count($class_ids)); for ($i = 0; $i < count($class_ids); $i++) { $stmt_params[] = &$class_ids[$i]; } call_user_func_array([$cooking_classes_stmt, 'bind_param'], $stmt_params); $cooking_classes_stmt->execute(); $cooking_classes_stmt->bind_result($class_id); while ($cooking_classes_stmt->fetch()) { var_dump($class_id); }

There seems to be a fixed limit of 40 result pages per search. However, you can go to the Advanced Search, manually(!) enter a date range and repeat this to browse through all posts.

Double-check the service documentation (or ask the provider) to see if they support any kind of unique transaction ID or nonce to prevent duplicate submissions. Then I wonder how the workflow looks like. Your own script also seems to be a webservice. Are you sure that it's only called exactly once? Finally: You said that the service fails to send any ACK segments. Did you actually see that in a packet sniffer, or is this just speculation?

If it's a public site, it's only natural that you get requests from all over the world and from all kinds of IP addresses. You can start worrying when the clients actually do something suspicious.

Which problem are you trying to solve? Spam? Excessive scraping? A security-related issue? Completely blocking IPs based on the decision of a third-party service is, obviously, problematic, because an IP can represent anything from a single client to thousands of (innocent) users. In the worst case, you end up with a self-inflicted denial-of-service attack. There are specific cases where the risk can be justified with a significant benefit (e. g. using the blacklists of The Spamhaus Project to prevent e-mail spam), but it's impossible to give any advice without knowing the context.

I would stick to the code you currently have. No magic.

With all due respect: Yes. Acting as a commercial hoster requires a professional infrastructure and a very solid security concept. Wordpress in particular is infamous for all kinds of vulnerabilities, so if you let random people install and manage their own Wordpress site on your server, that's nothing less than suicidal. I strongly recommend you stay away from this. At best, I'd host a few sandboxed, manually installed Wordpress installations for close friends. Anything beyond that is unrealistic.

Why do you want this? Executing administrative tasks with PHP or even running the script itself as root is generally the absolute last thing you want. The security of many PHP scripts is already scary enough, but a script with root privileges is orders of magnitudes worse. You need a damn good reason to take that risk.

What's wrong with this is that it's odd (hence difficult to read) and indicates a potential problem with your class design. If the instance is only (ever?) needed for a single method call, why even have an instance? Why not a static method or even a plain function? As always, it's better to show concrete code instead of making up some abstract pseudo-example.

Stick to one topic, don't try to solve ten problems at once. First off, what does a framework have to do with a text editor? Do you mean an IDE (integrated development environment) instead? An IDE can ideed help you write better code and avoid deprecated features. Which one you use is a matter of personal preferences. Try out Netbeans and Eclipse and see if you like them.

The real problem is actually something different: Your service is unable to recognize duplicate submissions (those can happen for all kinds of reasons, not just TCP issues). So the first thing you should do is introduce a nonce (number used only once) to your request and make your service reject all requests which have a duplicate nonce. For example: Generate a sufficiently long random ID for each request and send it along with the payload. On the server, create a table for all used nonces. A single nonce column declared as the primary key is sufficient. Whenever you receive a request, you try to insert the nonce into the above mentioned table. If that fails due to a duplicate value, you cancel the processing. Otherwise you continue.

What's your goal? Do you want to learn JavaScript? Or do you want to implement the dancing-men code with PHP? If you just want an implementation, forget about the JavaScript code and do it yourself. It's very easy, and you'll learn much more from your own implementation than from imitating somebody else's code. The logic is simple: for each character of the input: if character is alphabetic: if the word is terminated afterwards (space, end of string etc.): print the corresponding code with a flag else: print the corresponding code without a flag else if character is numeric: print the corresponding code else: (some fallback solution)

You can learn it.

I don't mean to put you down, but there's a lot to learn before you can use your code on any kind of real website. In fact, turning this project into a business might be a bit overambitious. You should concentrate more on learning the basics of programming and PHP in particular. You already seem to struggle with the basic PHP syntax. Do you understand that the “@” symbol in PHP denotes the error suppression operator? You do not put it in front of every variable. Actually, you shouldn't use it anywhere in your code. And as three(!) people already told you, the mysql_* functions are ancient. They have been removed from PHP and must not be used in new projects. Use PDO. Use PDO. Use PDO. Click on this link for further information. Maybe you should postpone your project for a few days and start with the basics like the PHP syntax and PDO. Otherwise you may end up with thousands of lines of bad code.

I would use the new random_bytes() function. If you don't have PHP 7 yet, you can plug in a compatiblity library for the time being. There's nothing inherently wrong with Mcrypt or OpenSSL, but relying on a single low-level extension can be problematic: None of them is available on all systems, and the Mcrypt extension is actually dying (the original library has been unmaintained for almost 10 years, and the PHP core developers already considered removing ext/mcrypt). The permission model sounds confusing, but you should probably create a separate thread for that.

The old MySQL extension is dead and has been removed from the current PHP version. You had 12(!) years to switch to one of the modern extensions, so, really, it's about time. And it's not only about keeping your code up-to-date. The old extension is notorious for causing SQL injection vulnerabilities, because most programmers simply don't understand the concept the SQL-escaping. PDO fixed that by introducing prepared statements. I understand that PDO looks a bit different, but it's very easy to learn with the above tutorial, and it actually makes a lot of sense. Prepared statements are a major improvement with regards to security. Instead of having to constantly write down the clunky while ($row = mysql_fetch_(...)) pattern, you now now use a simple foreach loop to iterate over rows. PDO works with all mainstream SQL systems, not just MySQL. That means you won't have to re-learn everything if you switch to a different systems (yes, this can happen).

Yes. A few things: Do the JSON-decoding on top of the script, check the return value to detect errors and log the exact error so that you have a chance to actually fix the problem. Without explicit error handling, PHP will crash somewhere and give you nothing but a cryptic error message. Avoid the use of backticks in queries, because this is unnecessary (as long as you use standard identifiers, which you should) and tends to mask errors.

@ilbiffi: You should forget this notion of “malicious characters” which somehow need to be “cleaned”. This is naive and misleading. Input data is just that: data. It may contain all kinds of characters, and that's perfectly fine. In fact, we would be in trouble if we weren't allowed to use quotes and other “special characters” in this forum. Security issues occur when data is misinterpreted as code. If, for example, you were to insert the decoded data straight into your query, you would indeed create an SQL injection vulnerability, because now the data is misinterpreted as part of the query. But you don't do that. By passing all dynamic input to the parameters of the prepared statement, you ensure that the data will always be treated as data and not executed in any way. There's no injection risk. You should, however, check if the JSON-decoding actually succeeded. Otherwise you'll get weird errors if the input is invalid.

mysqli_real_escape_string() is a mostly obsolete function for manual SQL-escaping (hence the name). It was needed in the early days of PHP when prepared statements weren't supported yet. Since we do have prepared statements now, it's pretty much useless. So, no, this function does not magically “sanitize” data (whatever that means). In fact, you cannot use it in conjuction with a prepared statement, because it will prepend literal backslashes to all quotes and other special characters, damaging your data. Simply use the prepared statement you already have and get rid of SQL escaping. Also get rid of the duplicate json_decode() call (unless that's just a copy-and-paste error).

This is your University project, not ours. We can help we you with small, specific problems, but we won't give you personal PHP lessons or even write the code for you. You don't know how to make dynamic queries? Learn it, start writing code, try to solve your own problems. That's really the whole point of a University project. When you're completely stuck, post the relevant code and tell us exactly what you don't understand.

This has nothing to do with the problem at hand.

You have some kind of output in line 1 before the opening PHP tag. That may be whitespace or a byte order mark or whatever. When in doubt, open the file in a hex editor. There mustn't be a single byte before the PHP tag.