То, почему использование является mysql, подготовило оператор, более безопасный, чем использование общих функций Escape?
У вас есть пара опций, самым простым из которых будет использование подписанных URL-адресов , чтобы позволить resend принять параметр пользователя id, тогда когда пользователь входит в систему и Убедитесь, что вы перенаправили их на страницу resend с их id для идентификации их учетной записи без активного сеанса пользователя.
Например, ваш контроллер входа будет выглядеть примерно так:
if (! $user->hasVerifiedEmail()()) {
return redirect()->to(URL::signedRoute('resend', ['id' => $user->id]));
}
И ваш метод VerificationController@resend будет выглядеть примерно так:
public function resend(Request $request)
{
if ($request->input('id') && $request->hasValidSignature()) {
$user = User::findOrFail($request->input('id'));
}
$user = $user ?: $request->user();
if ($user->hasVerifiedEmail()) {
return redirect($this->redirectPath());
}
$user->sendEmailVerificationNotification();
return back()->with('resent', true);
}
Тем не менее, Laravel включает в себя промежуточное ПО для запроса проверки электронной почты: оно разрешает вход в систему, но не позволяет пользователю ничего делать, пока они не подтвердят, поэтому, если у вас нет причин полностью запретить вход, промежуточное ПО удовлетворяет ваши потребности. Вы можете найти информацию о промежуточном программном обеспечении здесь .
6 ответов
Важный момент, который, я думаю, здесь отсутствует, - это база данных, которая поддерживает параметризованные запросы нет никакого «побега», чтобы беспокоиться о. Механизм базы данных не объединяет связанные переменные в оператор SQL, а затем анализирует все; Связанные переменные хранятся отдельно и никогда не анализируются как универсальный оператор SQL.
Отсюда безопасность и скорость. Механизм базы данных знает, что заполнитель содержит только данные, поэтому он никогда не анализируется как полный оператор SQL. Ускорение происходит, когда вы готовите оператор один раз, а затем выполняете его много раз; канонический пример - вставка нескольких записей в одну таблицу. В этом случае движок базы данных должен анализировать, оптимизировать и т. Д. Только один раз.
Теперь одна проблема связана с библиотеками абстракции базы данных. Иногда они имитируют это, просто вставляя связанные переменные в оператор SQL с надлежащим экранированием. Тем не менее, это лучше, чем делать это самостоятельно.
Например, вы оставляете экранирование опасных символов в базе данных, что намного безопаснее, чем вы, человек.
... он не забудет сбежать или пропустить какие-либо специальные символы, которые могут быть использованы для введения вредоносного SQL. Не говоря уже о том, что вы можете получить улучшение производительности для загрузки!
Я не очень разбираюсь в безопасности, но вот объяснение, которое, я надеюсь, поможет вам:
Скажем так у вас есть выражение вроде:
выберите [целое число] из mydb
Притворяться, что когда вы его готовите, оператор скомпилирован в байты в нашей воображаемой реализации SQL.
01 00 00 23
Opcode for select Prepared bytes number of "mydb"
for your integer
Теперь, когда вы выполните, вы вставите число в пространство, зарезервированное для вашего подготовленного оператора.
Сравните его с тем, что если вы просто используете escape, вы можете вставить туда столько тарабарщины и, возможно, вызвать переполнение памяти, либо какую-то команду bizzare sql, которую они забыли экранировать.
Потому что с готовыми заявлениями вы не можете забыть избежать содержимого. Таким образом, нет способа ввести небезопасность.
mysql_real_escape_string так же безопасна, как и подготовленные операторы, ЕСЛИ вы не забываете использовать mysql_real_escape_string каждый раз, когда вызываете mysql_query, но это легко забыть.
Функция небезопасна из-за этого эксплойта http://shiflett.org/blog/2006/ январе / addslashes-противы-MySQL-реальный побег струны . Вот почему подготовленные операторы являются предпочтительными, и это также повышает производительность.
Отлично случай, это не могло бы быть, но это по крайней мере одинаково безопасно;