#laravel #laravel-middleware #laravel-authentication #laravel-sanctum
#laravel #laravel-промежуточное программное обеспечение #laravel-аутентификация #laravel-sanctum
Вопрос:
В настоящее время я создаю API для мобильного приложения, но, думаю, я немного запутался в том, как должны работать проверка и аутентификация электронной почты. Я пытаюсь реализовать следующий поток:
- Пользователь регистрируется в мобильном приложении, и оно отправляет запрос в API
- Laravel создает пользователя и отправляет электронное письмо
- Пользователь получает электронное письмо и нажимает на ссылку
- Laravel проверяет пользователя и перенаправляет его в мобильное приложение по глубокой ссылке
Однако, когда пользователь нажимает на ссылку электронной почты, отображается ошибка «вход по маршруту не определен». Что имеет смысл, поскольку пользователь в данный момент не проходит проверку подлинности. Но я ошибаюсь?
Должен ли я аутентифицировать пользователя перед отправкой электронного письма? И будет ли это работать, учитывая, что мы используем Sanctum, а не «обычную» аутентификацию?
В настоящее время это то, что я делаю:
// web.php
Route::get('/email/verify/{id}/{hash}', [EmailVerificationController::class, 'verify'])
->middleware('signed') //note that I don't use the auth or auth:sanctum middlewares
->name('verification.verify');
// EmailVerificationController.php
public function verify(Request $request)
{
$user = User::findOrFail($request->id);
if ($user->email_verified_at) {
return '';
}
if ($user->markEmailAsVerified()) {
event(new Verified($user));
}
return redirect()->away('app://open'); // The deep link
}
Есть ли здесь какие-либо риски для безопасности? Должен ли я в любой момент аутентифицировать пользователя до или после того, как он нажмет на ссылку?
Я хотел максимально избежать рендеринга «веб-просмотров».
Комментарии:
1. Почему бы вам не отправить PIN-код пользователю по электронной почте для вставки в приложение? Таким образом, вам вообще не нужны веб-просмотры.
2. @WannyMiarelli На самом деле это хорошая идея. Но я все же предпочел бы попытаться понять, что именно здесь происходит. Однако будем помнить о ПИН-коде!
3. Я скопировал ваш код и могу завершить проверку без какой-либо проверки подлинности. Если вы перенаправлены на страницу входа в систему (логин маршрута не определен), это означает, что где-то этот маршрут попадает в фильтр авторизации. Трудно сказать, где из вашего извлеченного кода (может быть, какое-то глобальное промежуточное программное обеспечение?). Теоретически вы должны аутентифицировать использование перед проверкой электронной почты, но я не вижу проблем с безопасностью в обратном.
4. @WannyMiarelli это моя ошибка, я не дал понять, что именно это произошло до того, как я написал этот код в примере и удалил промежуточное программное обеспечение auth (если у кого-то есть права на редактирование, пожалуйста, исправьте это).). То, что я там сделал, было именно обходом аутентификации, и я хотел знать, все ли в порядке. Оказывается, это не совсем нормально, если бы не тот факт, что я не проверяю хэш. В итоге я выбрал маршрут PIN-кода. Однако позже я также захочу, чтобы пользователи входили в систему через веб-приложение, поэтому мне нужно будет решить, как отправить обычное электронное письмо с подтверждением в этом случае.
5. Я думаю, что это так же просто, как проверка источника. Если пользователь приходит из мобильного приложения, вы запускаете проверку PIN-кода, в противном случае запускается обычное электронное письмо.
Ответ №1:
Я думаю, что лучший способ — реализовать два разных пути, основанных на источнике пользователя.
Регулярная проверка электронной почты для пользователей, поступающих из браузера
Пользователь просто перейдет по ссылке, отправленной по электронной почте, вы можете сделать это с аутентификацией или без нее (возможно, с прозрачной аутентификацией cookie). Если проверка выполнена, перенаправьте их обратно на домашнюю страницу.
Мобильные пользователи, приходящие из мобильного приложения
Я бы отправил PIN-код (с каким-то механизмом истечения срока действия) по электронной почте и попросил бы их поместить его в приложение для проверки учетной записи. Это может быть защищено даже с помощью промежуточного программного обеспечения auth с использованием токена JWT с вызовом API проверки.
Я не вижу никаких проблем с безопасностью с этим последним.