Jacques1

I understand you want to get your task done. The problem, as I already told you, is that you struggle with PHP at a much more fundamental level: syntax, variables, basic form processing, database interaction, security and probably more. This needs to be resolved before we can even begin to discuss your problem, and I don't think anybody here has the time to give you personal lessons. I know it's tempting to just copy and paste random code from the Internet and then go to an online community to fix and adjust it. But there's a limit to this approach. You'll need at least a basic understanding of PHP. If you don't speak Japanese at all, you wouldn't expect people to help you write an epic novel in Japanese, right?

Oh my. Before you do anything, I suggest you start with a beginner's course for PHP (like the one on CodeAcademy). As long as you struggle with even the most syntax rules, it's pointless to try a complex project. Learn the basics of PHP, learn how to connect to a database system in the 21st century, then come back.

No, there is no way to get the client's timezone with PHP. As you probably know, PHP runs on the server, and the HTTP requests sent by the clients don't contain any timezone information. What you can do is try to get the timezone with JavaScript or make the user explicitly select their timezone. You can also use the IP address and a geolocation database to make an educated guess (but you still need a way for the user to correct the information).

Reading the replies also helps. As I've already told you, programming by trial-and-error doesn't work. Remove the parts which aren't relevant for the problem (like the mail stuff), learn how to use var_dump() and then analyze the problem systematically.

“vehicles” isn't the same as “vehicle”. Yes, you have to be exact. In any case, it's time for you to learn basic debugging steps. Forget about the e-mails. Right now, you cannot even assemble the message correctly, so it's nonsensical to add complex mail sending logic which may introduce even more errors. Remove the mail() call for now. Learn how to inspect variables with var_dump(). For example, var_dump($_POST) will tell you exactly what the $_POST array contains (and what it doesn't contain). When you're more experienced, check out professional debuggers like XDebug. This will save you a lot of time.

The comment is outdated, and it's not true that mysqli requires messy code for a dynamic number of parameters. PHP 5.6 introduced the splat operator which makes this trivial to implement: $searchTerms = explode(' ', $_POST['strings']); $searchStmt = $databaseConnection->prepare(' SELECT * -- list the specific columns! FROM core_table WHERE item_name IN (NULL '.str_repeat(', ?', count($searchTerms)).') '); $searchStmt->bind_param(str_repeat('s', count($searchTerms)), ...$searchTerms); $searchStmt->execute(); Nonetheless, PDO is the better extension.

There is nothing to be shown. You create as many parameters as you need, you pass the array to execute(), and that's it. $searchTerms = explode(' ', $_POST['strings']); $searchStmt = $databaseConnection->prepare(' SELECT * -- list the specific columns! FROM core_table WHERE item_name IN (NULL '.str_repeat(', ?', count($searchTerms)).') '); $searchStmt->execute($searchTerms);

Choosing the parameter type based on the PHP type doesn't make sense, because there is no simple one-to-one mapping. For example, large MySQL integers don't fit into PHP integers and must be stored in strings instead. So there are two options: Either you explicitly provide the types together with the input data. Or you cast the parameters in the query. ... CAST(:param AS INT) ...

Do you not understand that there's a difference between the number 80 and the string “$80”? Can't you see the dollar sign? This will fudge up any calculations, because PHP cannot convert that into a meaningful number (so it converts it to 0). You need to repair your database. The price must be stored in a numeric column (e. g. DECIMAL) without any currency symbols. If the currency is always the same, you don't need to store it at all. If there are different currencies, I recommend you store them in an additional column and then add the currency symbol in the application.

If the data comes from a third party (which is pure speculation), then you sanitize it before putting it into the database. Even the weakest programming language is far better at string operations than any MySQL hack. In any case, I'd be careful with literal answers. Users often fail to show their actual problem and only post random ideas they've come up with. Implementing those ideas may not solve the problem at all.

Where do those brackets even come from? When people need strange string manipulation hacks for their data, there's usually something wrong.

Then what is even the problem? Forget about this crazy output buffering stuff and just use the variables: $percentage = 0.1; $result = (1.0 - $percentage) * $row_product["rrp"]; echo 'The result is '.$result.'<br>'; This is basic programming. Your math also seems to be off. When you calculate $result - $value, you get a negative value. I'm fairly sure you want the opposite direction, i. e. 90% of the original value.

MySQL doesn't have CHECK constraints. You can create them, but they're completely ignored.

First, the code doesn't make any sense. Why on earth do you echo the content of a variable and capture the output in another variable? Why not just use the first variable? Secondly, you need to learn how to do basic debugging. Obviously your $row_product doesn't contain the data you think it does. So check how it actually looks like: var_dump($row_product);

And you tell us that now? Yeah, so much for the super-secure public-key handshake kung fu. This project is BS, and as a developer, you should be able to see through the fancy buzzwords. Once again: This is nonsense. What you're saying doesn't even make sense. Use an API key. If the client doesn't want HTTPS, they're obviously willing to take certain risks. So be it. Inventing your own nonsense protocol isn't going to help anybody. Do what you can and be honest about it.

What I said in #5: a strong API key.

This doesn't make any sense whatsoever. Do you actually want to provide a good solution for the client, or do you just want to throw buzzwords around, get paid and call it a day?

What method?

I'd clarify a few things to avoid getting into trouble. The proposed solution from the advisor is what? A specified goal everybody agrees on? A vague suggestion? Setting up public-key authentication is complex, time-consuming and requires a well-maintained PKI behind it. Let's say one of the private keys gets compromised -- now what? You either need a revocation mechanism (like a CRL), or somebody has to do your job all over again. Both isn't very realistic in your case. A much more appropriate solution is to generate a long random API key, hash it on the target server (plain SHA-256 is fine in this case) and set up standard HTTPS. If the client specifically wants public-key authentication regardless of the problems, fine. But I wouldn't implement it based on somebody-suggested-something.

This whole story doesn't add up. What exactly is your job? Are you only doing the code? Are you supposed to be the sysadmin of the two servers? Are you supposed to create and maintain a PKI? The shirt-sleeve let's-fumble-our-way-through-it approach may be OK if you want to secure, say, your personal blog. But it's downright dangerous when this is a professional environment where the client is “hot on security”.

When somebody has severe pneumonia, you don't “solve the problem” by leaving them alone with a bunch of cough drops. Do you not understand that? The warnings are just symptoms of a hopelessly misguided approach to database-related code. You can spend the rest of your career making those warnings go away, it doesn't help the OP one bit. In fact, you've made things worse, because now the OP has a) your vulnerabilities, b) your wrong error handling, c) wasted a lot of time on individual instances of the same underlying problem and d) left the application to die with the next PHP update. You still don't seem to get why we're recommending PDO. This is not about some “modern way”. It's about preventing people like the OP and you from shooting themselves in the foot.

The code you've provided is plain wrong. As the name already implies, mysql_real_escape_string() is for strings. When you apply it to identifiers, you simultaneously get an injection vulnerability and a bug. And this is exactly why keeping the old MySQL extension is unacceptable: It causes actual harm. It produces security vulnerabilities and defects all over the place. When even you can't get the code right, how on earth can you recommend it to somebody who you think is a bloody amateur? Your the-OPs-don't-care attitude is also worrisome. The code above obviously involves financial transactions, so, no, this isn't the right place for playing around and relying on luck. But even if it was a friggin' school project: Who are you to decide that somebody isn't worthy of correct advice?

“Working” is a meaningless term. The code is clearly neither tested nor peer-reviewed, so all you're saying is that you haven't looked for errors yet. Congratulations. That doesn't mean they don't exist, though: You access a session parameter which may not exist, and then you check if it exists afterwards. This is obviously nonsense and will lead to PHP notices (unless your error reporting is deactivated). You assign a variable to itself, which doesn't make any sense either. Your loop is entirely pointless, because it just overwrites the same variables over and over again. You're still running around with your “exisiting” typo. However, since nobody has any idea what you're even trying to do, it's impossible to tell you the best approach. All I can say is that the code you've shown in your recent threads looks very odd.

Now we're getting somewhere. I actually asked you if that's what you're worried about in my very first post. And now it's possible to give you a more nuanced answer: Yes, there are cases where the user ID in the session can be manipulated, even if the session data isn't directly exposed. Possible causes are a session poisoning vulnerability or a session directory which is shared among multiple applications or a vulnerability which gives the attacker write access to the session files. All of this happens and must be actively prevented. The ideal solution would be to make the user ID read-only. Unfortunately, that's not really possible with standard file-based sessions. An alternative is to calculate a message authentication code over critical data like the user ID, so that changes require knowledge of a secret key (i. e. simple manipulations are no longer possible). And of course you should systematically prevent the vulnerabilities I mentioned above: Use a separate session directory for each application. If your PHP environment uses the modern PHP-FPM API, consider setting up a separate pool with a separate Unix account for the application. This makes it a lot easier to prevent external file manipulations. Be very careful whenever you're writing data to the $_SESSION array. Make sure the array index cannot be influenced by the user. Sure, because really the whole point of the IDs is to act as (public) references within URLs etc. All you could do is have two IDs: a public ID which is exposed on the website frontend, and a long random internal ID which is only used on the backend. However, this is complicated and not very effective compared to the above suggestions.

Your user interface and the rotation are fairly awkward due to the “LEFT”/“RIGHT” input. I suggest you use positive/negative integers to indicate the direction. You can do this all with a single loop.