Jacques1

The permissions have already been explained. Now we're talking about a different problem.

What is the specific error message? Open the PHP error log (or whatever the application uses) and post the full message. MySQL connections don't just fail, there's always a detailed description of the reason. I also recommend you do some basic debugging before you hand over the problem. Like: Which of the two classes even gets loaded? The old “mysql” one? The new “mysqli” class? Are the connection parameters correct?

An even better starting point is to RTFM.

The way you use flock() generally makes no sense. Your while loop indicates you expect non-blocking behavior, but you haven't set the LOCK_NB flag, so the function is blocking. What do you want? If you switch to non-blocking behavior and simply wait and try, you can end up waiting forever.

Users will see their own ID and most probably the IDs of other users. For example, in the database of this forum, yours is 69813. Best approach to what? You haven't even defined the problem, so I'm surprised that you now claim you've found the solution. The description of a vulnerability typically looks like this: “If x manages to do y, then z happens”. In your case, who does what, and what are the consequences? Users can in fact see the internal database IDs. Why do you think this is a problem? You do have a problem if users can change the ID in the session (e. g. due to a session poisoning vulnerability).

If you want help with security, you have to be a lot more specific. The current description sounds more like a bunch of random ideas than a concrete problem. So you're storing the user ID in the session (which is pretty much unavoidable), and you're worried about ... what exactly? The user ID is public, so confidentiality isn't an issue. Do you think somebody might replace the user ID in their own session with the ID of somebody else?

Dumping raw user input into a PHP script means that anybody who can send a request to the script (directly or indirectly through CSRF) may inject arbitrary PHP code. You might as well have a textarea where people can execute code on your server. Even if the script was completely isolated from the Internet and only used by friendly people, it would still be a bad idea, because code injections can happen purely by accident and will then break the application permanently. For example, try a password with a single quote or a backslash at the end. You really need to adopt a more robust, less naive way of programming. If you absolutely must create configuration files programmatically (which is inherently risky), then use non-executable formats like JSON, XML, YAML, ... We already had that discussion in your last thread. Also note that the “var” syntax for object attributes comes from PHP 4 and is obsolete since more than a decade (I was surprised that it still works).

PHP doesn't have block scope. Statements like foreach, if etc. do not introduce a new variable scope (like they would in Java or C).

The code makes no sense. You cannot combine a global declaration of a variable with other operations. The $body variable obviously isn't even global; it's a local variable of the function. So I suggest two things: Learn what global means (or avoid it altogether). And get an IDE, as we already discussed.

I wouldn't rely on a one-guy-project that was last updated 4 years ago, especially since authentication is kinda critical. If CodeIgniter is any good, there's an official or at least well-established authentication module. Look for that, not random GitHub repositories.

The PasswordHash class is ancient. It was written more than a decade ago (appearently for PHP 4) and never updated since. It's also entirely useless, because PHP 7 has its own Password Hashing API. No need for any external libraries.

You haven't understood the question. I'm asking why each user gets his own database and server role. This is extremely unusual and only makes sense if all users are database administrators who need direct access to the database server (which would also be unusual). Normally, users have an account within the application, and there's just one database and role. This forum has thousands of users. That certainly doesn't mean we all have our own credentials to the database server. We just have an application account. By checking the PHP configuration. If you don't know where that is, ask the server admin or use Google. The PHP error log. If you don't know where that is, ask the server admin or use Google.

Even if there is a converter, the result will be horrible. Writing decent code is a complex task which requires a skilled human. So switching from one language two another means you have to start from scratch. You may be able to adopt a few ideas, HTML fragments etc., but that's it.

It's an IQ test.

Now you're doing an OR check, which means anybody can log-in without a password if they enter a valid username. You need an AND check (&&). // Or rather: Leave out the username check altogether. It's already in the query.

First off, you need to get rid of this strip_tags() nonsense. This can in fact destroy your passwords, because it blindly removes anything that looks like HTML markup. The password_verify() function works like this: if (password_verify($the_password_to_be_checked, $the_stored_password_hash)) { // correct password } else { // wrong password }

Like I said above: Use a standard format like JSON or XML. PHP already has parsers for those. For example: config.json { "name": "some_name", "description": "some description", "version": "1.0", "author": "RMorrison" } Parsing: <?php $config_content = file_get_contents('/path/to/config.json'); $config = json_decode($config_content, true); // echo the version number for testing echo $config['version'];

It sets an HTTP header, that's it. The control flow of the script isn't affected in any way. Redirection happens client-side after the response has been sent. That's when the client may or may not decide to follow the URL in the Location header.

No, the script keeps running. Setting the Location header just sets the header, it doesn't magically stop the script.

My point is that any user or service with write access to the modules folder can inject code into the core application, which is an unncessary risk. The modules should be explicitly approved before anything gets loaded. The info file should not be an executable script, otherwise you run into the exact same security issues. Use a data format like JSON, XML or whatever. Correct.

I use PhpStorm. However, it's fairly expensive if you don't meet the requirements for a discount. A good free IDE is Netbeans.

We can speculate all day long about what might be wrong, but I suggest you just look it up. Open the error log and look for warnings which say something like Warning: pg_connect(): Unable to connect to PostgreSQL server: ... If there are no warnings, make sure your error reporting is turned all the way up. The whole approach is ill-advised, though. When you insert the user input into the connection string, those users can mess with the connection parameters (maybe even by accident), execute arbitrary SQL commands, see what files exist on your server etc. You don't want that. Why are users even supposed to have their own database credentials?

If you only want the row count, then it's extremely inefficient to load the entire table into PHP. Let MySQL do the counting: <?php $userCount = $db_con->query('SELECT COUNT(*) FROM users WHERE enabled')->fetchColumn(); $voteCountStmt = $db_con->prepare('SELECT COUNT(*) FROM votes WHERE motions_id = :motionid'); $voteCountStmt->execute(['motionid' => $motionid]); $voteCount = $voteCountStmt->fetchColumn(); If you want both the count and the actual data, then use fetchAll() in both cases. When you use fetch(), you only get a single row, regardless of how big the result set actually is.

This is a rather messy approach. On top of that, you'll quickly end up with a local file inclusion vulnerability if you dump anything that starts with “admin_” into your application with no checks whatsoever. A much better solution would be to store the modules as folders. Each folder may contain a meta file containing information about the module itself (a user-friendly name, a short description, a version etc.). The modules should then be explicitly activated.

You're using fetch() for the second query, which returns a single row. When you apply count() to that row, you're counting columns, not rows. What's the point of that counting stuff anyway? You expect one row, you fetch one row, yet for some reason you check for more than one row. What's the real problem here?