База данных часто реагирует на запросы через PHP

В настоящее время я снимаю волосы по этой проблеме уже целый день. Я разрабатываю свое первое приложение. Я на самом деле довольно далеко (установил страницу входа несколько недель назад, отлично работал). Прошлой ночью я запустил приложение и отлично работал. Я поддержал его на своем флеш-накопителе, проверил его еще раз и закрыл ноутбук на ночь.

Сегодня утром я открыл приложение, чтобы начать процесс документирования – это проект для моего ключевого слова, поэтому я должен документировать / видео результат каждую неделю, и вдруг мой счетчик тестеров не может быть аутентифицирован. Я попытался зарегистрировать новый через приложение, и он не отправляет данные в базу данных. Естественно, я предположил, что у базы данных / сервера возникли проблемы и связался с моим хостом; в течение двухчасового периода они подтвердили, что база данных работает, и это было просто в моем коде, который не был затронут с той ночи, когда он работал отлично.

Я читал, что это иногда происходит с аутентификацией через FireBase (я считаю, что это то, что она называется) и OAuth. Я не использую ни одно, ни просто чтение / запись базовой базы данных. Я не нашел никакой полезной информации о том, что делать через Google, возможно, из-за того, что проблема слишком сложна для быстрого поиска … или я просто не знаю, как правильно это сформулировать.

<?php $connection = mysqli_connect("localhost", "SENSORED", "SENSORED", "SENSORED"); $username = $_POST["username"]; $password = $_POST["password"]; $statement = mysqli_prepare($connection, "SELECT * FROM user WHERE username = ? AND password = ?"); mysqli_stmt_bind_param($statement, "ss", $username, $password); mysqli_stmt_execute($statement); mysqli_stmt_store_result($statement); mysqli_stmt_bind_result($statement, $user_id, $name, $username, $email, $company_id, $phone, $password, $leaveTime, $sickTime, $rateOfPay); $response = array(); $response["success"] = false; while(mysqli_stmt_fetch($statement)){ $response["success"] = true; $response["user_id"] = $user_id; $response["name"] = $name; $response["username"] = $username; $response["email"] = $email; $response["company_id"] = $company_id; $response["phone"] = $phone; $response["password"] = $password; $response["leaveTime"] = $leaveTime; $response["sickTime"] = $sickTime; $response["rateOfPay"] = $rateOfPay; } echo json_encode($response); ?> 

Я установил тест соединения, который подтвердил, что PHP действительно подключается к базе данных и запрашивает ее. Он может определить, сколько таблиц у меня есть, и, например, сколько имен пользователей в таблице пользователя. Однако, когда я вхожу:

 "SELECT * FROM user WHERE username = 'test'" 

что есть имя пользователя, которое просто «тест», оно не может найти совпадение. Тем не менее, я вижу, глядя на базу данных, что тест действительно является именем пользователя и существует в этой таблице.

Я не получаю результатов через PHP. Однако, если я запрашиваю через PHPmyadmin, он отображает строку, которая содержит «test» в качестве имени пользователя. Очевидно, что мое кодирование верное, но я не уверен, что может помешать его выбору с PHP, поскольку он устанавливает соединение и считывает из базы данных. Не говоря уже о том, что он не хочет записывать регистрационную информацию в базу данных, если в ней нет трюков.

Я зашел так далеко, что искал решение как создание целой новой базы данных с разными учетными данными и т. Д. И получал ту же проблему. Google не помог в поиске ответа, и мне не удалось найти аналогичный вопрос / проблему здесь.

Любая идея о том, как работоспособное соединение с базой данных и возможности чтения / записи могут полностью исчезнуть без изменения в одночасье?

Solutions Collecting From Web of "База данных часто реагирует на запросы через PHP"

вот как я это сделаю. Как я уже сказал, я не использовал MySqli в течение нескольких лет, поэтому мне пришлось делать некоторые поисковые запросы, и я не уверен на 100%, что все правильно, поскольку я не могу это проверить.

Но здесь идет.

  //turn on output buffering - useful for debugging ob_start(); //I would use the object interface $mysqli = new mysqli("localhost", "SENSORED", "SENSORED", "SENSORED"); //your not checking the connection success if (mysqli_connect_errno()) { printf("Connect failed: %s\n", mysqli_connect_error()); exit(); } $username = $_POST["username"]; //are you storing passwords in plain text? $password = password_hash($_POST["password"]); /* I would not pick the password from the DB, the DB is case insensitive, unless you use collation UTF8_bin or such. Also it's harder to debug, as you don't know if the user exists or the password matching is wrong. */ $stmt = $mysqli->prepare($connection, "SELECT * FROM user WHERE username = ?"); //bind the inputs $stmt->bind_param("s", $username); //execute the query $res = $stmt->execute(); //fetch results as an associative array $row = $res->fetch_assoc(); //set default $response["success"] = false; /* We expect exactly 1 row be returned. More then 1 should be impossible if your username is unique (which is should be) but just in case any issues happen we should check that it's exactly 1 return row, no more no less. */ if($res->num_rows() != 1) { //always be cordial in your error messages to users $response['message'] = "We're sorry we could not find user {$username}"; return $response; } //check the password hash using an approved crypto-logically safe method if(!hash_equals($password, $$row['password']) { $response['message'] = "Unfortunately the password you entered is incorrect"; return $response; } //remove the password / we no longer need it. //security is paramount, no need to risk exposing it, even when its hashed //eg. I just spent the weekend fixing 5 wordpress sites that were hacked unset($row['password']); $response['message'] = "Success!"; //put the contents of the buffer into debug. only do this on localhost //you could switch this using the HOST or server IP $response['debug'] = ob_get_clean(); //combine the row with the response //caution if key matched in rows exists in response value in row //will be replaced with that of response ( it shouldn't be a problem in this case ) $response += $row; //set the correct content type, this allows browsers to //know this is json, and prevents having to do JSON.parse() in some cases header('Content-type:application/json'); //encode the responce echo json_encode($response); с  //turn on output buffering - useful for debugging ob_start(); //I would use the object interface $mysqli = new mysqli("localhost", "SENSORED", "SENSORED", "SENSORED"); //your not checking the connection success if (mysqli_connect_errno()) { printf("Connect failed: %s\n", mysqli_connect_error()); exit(); } $username = $_POST["username"]; //are you storing passwords in plain text? $password = password_hash($_POST["password"]); /* I would not pick the password from the DB, the DB is case insensitive, unless you use collation UTF8_bin or such. Also it's harder to debug, as you don't know if the user exists or the password matching is wrong. */ $stmt = $mysqli->prepare($connection, "SELECT * FROM user WHERE username = ?"); //bind the inputs $stmt->bind_param("s", $username); //execute the query $res = $stmt->execute(); //fetch results as an associative array $row = $res->fetch_assoc(); //set default $response["success"] = false; /* We expect exactly 1 row be returned. More then 1 should be impossible if your username is unique (which is should be) but just in case any issues happen we should check that it's exactly 1 return row, no more no less. */ if($res->num_rows() != 1) { //always be cordial in your error messages to users $response['message'] = "We're sorry we could not find user {$username}"; return $response; } //check the password hash using an approved crypto-logically safe method if(!hash_equals($password, $$row['password']) { $response['message'] = "Unfortunately the password you entered is incorrect"; return $response; } //remove the password / we no longer need it. //security is paramount, no need to risk exposing it, even when its hashed //eg. I just spent the weekend fixing 5 wordpress sites that were hacked unset($row['password']); $response['message'] = "Success!"; //put the contents of the buffer into debug. only do this on localhost //you could switch this using the HOST or server IP $response['debug'] = ob_get_clean(); //combine the row with the response //caution if key matched in rows exists in response value in row //will be replaced with that of response ( it shouldn't be a problem in this case ) $response += $row; //set the correct content type, this allows browsers to //know this is json, and prevents having to do JSON.parse() in some cases header('Content-type:application/json'); //encode the responce echo json_encode($response); 

Я помещал там некоторые заметки, такие как

 //always be cordial in your error messages to users 

Когда-то был молодой веб-разработчик, у которого был клиент, который жаловался, что его сообщения об ошибках были «холодными». Но этот молодой веб-разработчик настороженно отзывался о своих клиентах и ​​помнил, что всегда должен быть приятным для конечных пользователей. (это было около 2009 года). Тем не менее, это не улучшило мое правописание.

Одна вещь, с которой я столкнулся во время рефакторинга, заметил, что вы не шифруете пароль. Я не знаю, если это по ошибке или по дизайну.

ob_get_clean и ob_get_clean позволяют вам echo или print_r между ними, не нарушая ответ JSON . Обычно, если вы создаете вывод, он будет за пределами ваших json-данных

  here is some output {"success" : false} 

Это вызовет ошибки на стороне клиента. С буферизацией вывода выше будет выглядеть так:

 {"debug" : "here is some output", "success" : false} 

Я полагаю, что это необязательно, но это правильный способ сделать JSON или даже любой тип контента, отличный от HTML, включая (или особенно) загрузку файлов.

Надеюсь, поможет. Даже если вы не можете использовать код в этой форме, это может помочь увидеть, что это написано по-другому. Иногда вы можете приблизиться к проблеме и пропустить какую-то простую ошибку. Взглянув на него в другом формате и вынудив его обработать, может пролить свет на то, что вы пропустили.