Jacques1

SMTPS on port 465 was deprecated back in the 90s (the port is now reserved for a completely different service). The standard way for mail submission over TLS is to start a plaintext connection on port 587 and then upgrade the protocol with the STARTTLS command. Port 25 is actually reserved for server-to-server communication, but some systems may still accept e-mail submission for legacy reasons. In any case, you have to make sure that the connection is in fact encrypted (check both the configuration and the traffic). As I already said, the client has to request the protocol update. If that doesn't happen, everything is plaintext, even when the server does support TLS.

Then they probably shouldn't be two tables.

Both thephpleague/oauth2-server and bshaffer/oauth2-server-php are very active, have been around for a while and are in fact mentioned on the “official” site (if that helps). But even if the project dies in a couple of years – so what? Switching to a different library is still much, much less work than writing your own from scratch and maintaining it (just look at the number of contributors and commits). You could even implement an abstraction layer (e. g. a couple of wrapper functions), so that the application doesn't rely on any library-specific features.

Or rather: Use them. Reinventing OAuth might be a nice project if you're interested in protocol design itself, but it's a waste of time and a significant risk if you try to use your own protocol as an ad-hoc solution. Misunderstandings and bugs can be fatal in a security context. OAuth 2.0 is an established and well-tested protocol which should cover just about every scenario. Use it.

So you do want to change the underlying HTML markup. As I already said, this cannot be done with the function you've posted. You have to go to the code or template where the actual markup is generated. You can try searching for the usages of the above function. This should get you closer.

If you want an entirely different HTML markup (e. g. classical submit buttons rather than images), the function won't help. You'll have to look up the code where the markup is generated and change that.

Unfortunately, even the PHP manual teaches this practice in the example code. The fact that PDO defaults to using two entirely different error handling mechanisms depending on the method isn't helpful either. So the constructor throws an exception which should not be handled, but then all other methods use return values which must be handled – unless exceptions are turned on, in which case the other methods throw exceptions as well. It's like they want programmers to screw up.

Sorry, but “Come answer my Stackoverflow question” doesn't work as a thread here. You should also preview your posts, because obviously you have trouble with the copy-and-paste feature of your browser.

I'm not sure why PHP programmers are so obsessed with PDO exceptions. A PHP script can generate dozens or even hundreds of different exceptions, errors, warnings and notices. What about those? If you wanted to handle each one of them individually like you do with PDOException, you'd have to write an error handler for almost every line of code. And then you still haven't done anything about the errors which happen before runtime. This obviously makes no sense. If you display the error messages to the user (which many programmers like to do for some reason), that's even dangerous, because they often contain sensitive information about your application or system. So what we do instead is set up a global error handler. The default handler actually works very well, so most of the time, you have to do nothing but configure your php.ini appropriately: In production, you disable display_errors and enable log_errors. This writes all errors to a logfile and at the same time emits a 500 status code which can be used to display a user-friendly error page (“Sorry, but there was an internal error. The administrator has been notified.” etc.). During development, you enable display_errors so that you can see all revelant information (not just the message!) directly on the screen. What more do you need? Catching an exception is only valid when you have a specific error handling strategy for this specific problem, which is very, very rare. For example, in some cases it makes sense to retry the action or switch to a backup routine. But most of the time, you just want to make the error information available to the developers and display a nice page for the users.

This is an English community.

The code is a mess. I see the same problems in many of your threads, and I've pointed them out multiple times. It would be great if you actually learned from them: Stop rAnDoMlY CHanGIng ThE lETer CASE. Identifiers in PHP (and the various database systems) are almost always lowercase. So it's “public” instead of “Public”, “$address” instead of “$ADDRESS”, “sleep” instead of “SLEEP” etc. This is not just a cosmetic issue. Mixing name conventions massively increases the error rate and decreases readablity. Use meaningful names. Looking at the method signature, I have absolutely no idea what the method is supposed to do. In fact, the name “get” indicates that it's a getter, but obviously it does something entirely different. Your table names “plout” and “postss” can also be improved. Don't use magic return values to indicate the result. In fact, don't use magic numbers at all. The function sometimes returns 0, sometimes 1 and sometimes an array. Again, nobody has the slightest idea what that even means. In a couple of months, even you probably don't know. If there's an error, just throw an exception. Don't randomly catch PDO exceptions. When there's a database error, you almost always want PHP to abort the script in a controlled manner and not keep running. A debugger can help you avoid cluttering your code with echo and var_dump() statements (but I understand this can be a challenge for a beginner). Before you start typing on your keyboard, make a plan of what you want to do. What is the purpose of the method? It doesn't matter. Both is valid.

This is also a textbook example of insecure programming. The above code fragment alone is vulnerable to XSS, CSRF, replay attacks and probably path traversals. In fact, you don't even know what you're deleting. There is no hash or checksum of any kind to tell you whether the file you're about to remove is actually the one you've scanned. It might have a completely different content. I understand your goal. But the approach you've chosen is so fundamentally flawed both on a conceptual and technical level that it's effectively malware itself. This has nothing to do with personal opinions. It's about technical facts. If you're willing to put the code aside and re-evaluate the original problem as benanamen suggested, I'm sure we can help. You could also just keep sending mails and not mess the files. But we can't help people put their users at risk.

I wouldn't use the === operator to have a “spare =”. The purpose of === is type safety. You use it when the type is needed as additional information to distinguish between multiple values (e. g. the integer 0 and the boolean false in a boolean context; strpos() is a classical use case). Type-safe comparisons are also used in critical features to prevent bugs. But that's it. When you routinely do === comparisons, you're going against the type system which is weak by design. The fact that we can write if ($an_array) { // not empty } else { // empty } or if ($a_string) or "1234" == 1234 is how it's meant to work.

Your admin area makes everybody an admin: if ($_SESSION['myAdmin'] = true) ^ This is an assignment, which means the condition is always true. You probably wanted to check for == true, but this doesn't make much sense either. The variable $_SESSION['myAdmin'] is already a boolean. It doesn't get any “truer” or “falser” by doing comparisons. Just use it directly: if ($_SESSION['myAdmin']) This is also much safer against typos. What's the session_destroy() in the log-in script supposed to do?

It's not. But it's a lot easier to use and works with all mainstream database systems, not just MySQL. mysqli is a low-level interface, which means the programmer has to do a lot of work to get things done, and many steps aren't very intuitive. Executing a prepared statement and fetching the data requires no less than five(!) different functions. With PDO, you just need PDO::prepare(), PDOStatement::execute() and one of the fetch methods (you can even iterate over the result set with a foreach loop). Even worse, mysqli creates a “vendor lock-in”. You can't just switch to a different database system, even if it can run all your SQL queries just fine. You'd have to go through your entire code, remove the mysql parts, learn a new interface and start all over again. With PDO, you just have to change the parameters of the initial connection and maybe update a few queries where you use MySQL-specific syntax.

SO_REUSEADDR

It's easy to remember (for those who know the meme), outside of the well-known ports and not registered. That makes it a good candicate for example code and testing.

You can't, at least not in your current workflow. You'd have to create an extra form which the user then has to submit only to help you pass internal data around – which obviously makes no sense. This also violates the purpose of POST request (which are meant to modify data). Use a cookie, session variable or URL parameter. Anything but a POST request.

No. mysqli should be phased out entirely or at least turned into a “hidden” extension for special purposes. But as long as its marketed as an easy way out of the ext/mysql deprecation, it won't go away anytime soon.

Leet

The OP is using mysqli, so it's not quite that easy: $client_update_stmt = $mysqli->prepare(' UPDATE clients SET fname = ?, lname = ?, email = ?, phone = ? WHERE id = ? '); $client_update_stmt->bind_param('ssssi', $_POST['fname'], $_POST['lname'], $_POST['email'], $_POST['phone'], $_POST['id']); $client_update_stmt->execute(); There doesn't seem to be any kind of CSRF protection, though. This means anybody can manipulate or delete the data by making the admin visit a website with a piece of JavaScript code or a button that triggers a POST request. You need to fix that. Besides session-based authentication (which I hope you've already implemented), you also need to authenticate every single POST request with a secret token.

The React classes are explicitly designed as (relatively simple) wrappers for the PHP stream functions to implement client-server communication over sockets. Anything beyond this is out-of-scope.

Why make the webserver the owner of the script and give it write access? The webserver only needs read access, so it should have nothing but that. And what about CSRF protection? Clickjacking protection in every variation? File traversal protection? etc. I know a bit about PHP, and even I wouldn't be comfortable writing this script. If at all, I'd write a CLI tool. I'm not really talking about utilities, rather classical system administration: Read-only application infrastructures, multiple PHP-FPM pools running under different Unix accounts, Linux containers so that you can reduce the damage and quickly go back to a sane state (without manual “clean-ups”). Sure, that may be less fun than writing a tool. But I believe it's much more effective.

It's definitely better to use .ini files than clutter your code with runtime settings. The error_reporting() call doesn't even work for all errors, because they may happen before the script is run (syntax issues, internal PHP problems etc.). The manual explains where exactly .ini files must be placed. Global settings can be done in the system-wide php.ini (which may already exist; check phpinfo() for the path). Application-specific settings should be done in the webserver configuration for the virtual host or in the top-level directory of the application (e. g. a .htaccess file for Apache).

The whole approach sounds strange. First off, a web-facing script with write access to critical files will be a very juicy target for the very people you're trying to protect yourself from. PHP scripts are notoriously difficult to secure, so you'll quickly end up decreasing your overall protection. Secondly, scanning files with some home-made “hacker detection” script and relying on laymen(?) to simply delete the files is just not appropriate. Script infections are very serious and can compromise large parts of the system. This requires a professional admin or security expert with SSH access to the system. If your server is regularly infected, you definitely need to revise your security concept. For example, core scripts and directories shouldn't even be writable.