I’ve been trying to create a log in form that intakes a hashed password and verifies it (my encryption method is bcrypt.) The only error showing on-screen is Notice: Trying to get property 'num_rows' of non-object in C:\xampp\htdocs\affc\login.php on line 34
{
$acc_username = $_POST['affc-username'];
$acc_password = $_POST['affc-password'];
$sql = "SELECT * FROM users WHERE username='$acc_username'";
$result = $conn->query($sql);
if ($result->num_rows === 1) {
$row = $result->fetch_array(MYSQLI_ASSOC);
if (password_verify($acc_password, $row['password'])) {
echo "Match";
} else {
echo "The username or password do not match";
}
}
}
This error (and the initial error you were getting in your previous thread) are follow-on php errors, having nothing directly to do with what’s causing the problem. They are due to a database operation that has failed and that your code doesn’t have any error handling to tell you if and why the database statement has fail or to stop the following code from trying to use the result from a database statement that has failed.
The easiest way of adding error handling for all the database statements that can fail - connection, query, prepare, and execute, is to use exceptions for database errors and in most cases let php catch and handle the exception, where php will use its error related settings, via an uncaught exception, to control what happens with the actual error information (database statement errors will ‘automatically’ get displayed/logged the same as php errors.) To enable exceptions for errors for the mysqli extension add the following line of code before the point where you make the database connection (you can then remove any existing hard-coded database error handling logic, as all it will do is give hackers useful information when they intentionally trigger errors) -
In your previous thread, you were using a prepared query to provide protection against sql special characters in values from breaking the sql syntax (which is how sql injection is accomplished.) Why have you taken a step backwards and are now putting external, unknown, dynamic value(s) directly into the sql query statement? If this is because of how overly complicated and inconsistent the mysqli extension is for prepared queries, now would be the time to switch to the much simpler PDO extension. The PDO extension lets you treat the result from a non-prepared and a prepared query in exactly the same way so that you don’t need to learn and use two different sets of php statements.