Я пришел к тому моменту, когда я должен решить, какой метод использовать:
Я создал файл ChangePassword.php, где я проверяю данные и затем изменяю пароль. Что лучше?
или же
A. версия:
// Check for valid session
$qry = $db->prepare('SELECT id FROM userData WHERE id = :userId and session = :session');
$qry->bindParam(':userId', $userId, PDO::PARAM_INT);
$qry->bindParam(':session', $session, PDO::PARAM_STR);
if ($qry->rowCount() <= 0) {
// Invalid session
exit("Invalid Session");
}
// Valid session
// Check for correct password
$qry = $db->prepare('SELECT id FROM userData WHERE id = :userId and password = :passwordHashed');
$qry->bindParam(':userId', $userId, PDO::PARAM_INT);
$qry->bindParam(':passwordHashed', $passwordHashed, PDO::PARAM_STR);
$qry->execute();
if ($qry->rowCount() <= 0) {
// Incorrect password
exit("Incorrect Password");
}
// Update Password
$qry = $db->prepare('UPDATE userData SET password = :newPasswordHashed WHERE id = :userId');
$qry->bindParam(':userId', $userId, PDO::PARAM_INT);
$qry->bindParam(':passwordHashed', $passwordHashed, PDO::PARAM_STR);
$qry->bindParam(':newPasswordHashed', $newPasswordHashed, PDO::PARAM_STR);
$qry->execute();
if ($qry->rowCount() > 0) {
// Successful edit
exit("SUCCESS!");
} else {
// Unsuccessful edit
exit("Uknown Error...");
}
B. версия:
// Check for valid session, correct password and update password too
$qry = $db->prepare('UPDATE userData SET password = :newPasswordHashed WHERE id = :userId AND session = :session AND password = :passwordHashed');
$qry->bindParam(':userId', $userId, PDO::PARAM_INT);
$qry->bindParam(':session', $session, PDO::PARAM_STR);
$qry->bindParam(':passwordHashed', $passwordHashed, PDO::PARAM_STR);
$qry->bindParam(':newPasswordHashed', $newPasswordHashed, PDO::PARAM_STR);
$qry->execute();
if ($qry->rowCount() > 0) {
// Successful edit
exit("SUCCESS!");
} else {
// Unsuccessful edit
exit("Maybe invalid session, or wrong password, or unknown error? Decide! :D");
}
Каково твое мнение?
Решение A было бы более важным для меня, потому что я хотел бы сообщить пользователям об ошибке, но также я хочу сказать, будет ли это замедлять базу данных из-за запросов на покупку.
Я не стал бы беспокоиться о количестве запросов, которые запускаются на странице ChangePassword.php. Сколько раз в секунду пользователи будут отправлять эту форму? Это не похоже на страницу, которая будет использоваться 1 раз в 1000 по сравнению с более общей страницей, такой как ваша домашняя страница.
Другими словами, наиболее тщательно оптимизируйте страницы, которые будут запрашиваться часто. Не будьте слишком обеспокоены тонкой оптимизацией для страниц, которые запрашиваются редко.
Я также хотел бы сказать, что если производительность проверки сеанса была важна для масштабируемости вашего приложения, вы не сохранили бы сеанс в постоянной базе данных - вы сохранили бы его в кеше, таком как Memcached или Redis.
Я мог бы даже сказать далее, что если на вашем сайте было так много пользовательского трафика, что страница "ChangePassword" запрашивалась много раз в секунду и требовала высокой масштабируемости, тогда вы использовали бы другой внешний язык, например Java или Go, а не PHP.
Когда вы говорите о функциях безопасности, а также в модуле пароля изменения, вы должны воспользоваться опцией, которая обеспечивает наилучшую обработку ошибок (вариант A). Вы должны изучить тот фактор, который не каждый в одно и то же время изменит свой пароль или будет делать это часто (это не произойдет ежедневно, еженедельно или ежемесячно).
У вас может быть много запросов в файле ChangePassword.php, потому что люди не будут использовать его часто и одновременно. Обычно люди меняют свой пароль, когда система сообщает им, что им приходится (каждые 6 месяцев, например).
Решение B было бы моим предложением, вы не хотите информировать пользователя о точной ошибке, поскольку он предоставляет ненужную информацию, которая может помочь им атаковать веб-сайт. Он также более эффективен, так как дополнительный выбор будет устанавливать дополнительную нагрузку на базу данных.
решение два лучше (если вы можете выбрать меньше запросов всегда лучше)