Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Если я правильно понял, то в приведённом ниже примере из документации по ручной аутентификации метод attept сверяет данные с данными в таблице users:
public function authenticate(){
if (Auth::attempt(['email' => $email, 'password' => $password])) {
// Аутентификация успешна
return redirect()->intended('dashboard');
}
}
Если так, то встаёт вопрос — а как же сверять данные с какой-либо другой таблицей? Я уже посмотрел имеющиеся ответы на этот вопрос, и везде показывали, как эту таблицу менять глобально. Я хочу оставить таблицу users и в одних случаях сверять данные с этой таблицы, но в других — с другой таблицей.
Предвижу ответ: «Локально указаться таблицу при конструировании запроса невозможно». Если так, то хорошо, не критично: сравнить данные можно и без Auth::attempt, и я уже это реализовал. А вопрос такой: как теперь вручную проверять, авторизован ли пользователь, если до этого фасад Auth вообще не использовался?
У Вас наверняка возникнет вопрос, что я такое вытворяю, для чего всё это. Задача специфическая; не готов утверждать, что выбрал лучший путь. У меня две аутентификации: одна для админов, которая даёт доступ к админ-панели, другая — для заказчиков, которая даёт доступ к его сайту, находящемуся в процессе разработки и временно являющегося частью моего сайта. Может, это можно реализовать и через авторизацию, но эти две аутентификации совершенно для разных целей и для каждой аутентификации необходимы разные наборы данных (отсюда — две таблицы под каждую идентификацию). Например, у каждого заказчика есть поле в БД «номер заказа» — администратору такое поле незачем.
Изменено Gleb2708 (21.11.2017 16:07:48)
Не в сети
Ты переизобрел велик. Такая же задача есть в 80% Laravel приложений и решается она стандартной аутентификацией.
Не в сети
Хорошо, но как? Как решается эта задача, если:
— Макеты с формой входа пользовательские и они лежат во views, но там, где мне надо (не в стандартном пути, генерируемом php artisan make:auth). На данный момент страница входа в закрытую зону сайтов в разработке — такая же открытая страница, как и многие другие потому маршрут к ней определяется так:
Route::get('/login_to_sites_in_development_zone',
[ 'as' => 'loginToSitesInDevelopmentZonePage',
'uses' => 'MainController@renderLoginToSiteInDevelopmentZonePage']
);
— Разные таблицы с разными данными для админов и заказчиков. На данный момент аутентификацию для админов я ещё не проработал, но уже организовал последовательную проверку номера заказа и соответствующего пароля с выводом пользовательских ошибок. То есть у меня выводит что-то поинтереснее, чем стандартное Laravel-сообщение об ошибке:
if (is_null($orderIdInDB)) {
return Redirect::route('loginToSitesInDevelopmentZonePage')->withErrors(['wrongOrderId' => true])->withInput();
}
xml @if ((bool) $errors->first('wrongOrderId')) <div class="signInForm-errorMessagebox" id="invalidID-errorMessage"> <div class="signInForm-errorMessagebox-heading">Неверный ID заказа</div> <div class="signInForm-errorMessagebox-contains"> Вы ввели неверный или несуществующий ID заказа.</div> </div> @endif
— Регистрация и сброс паролей не требуются, меня сейчас интересует только аутентификация. Соответственно большинство того, что создаётся php artisan make:auth — лишнее.
Изменено Gleb2708 (21.11.2017 17:24:09)
Не в сети
Макеты с формой входа пользовательские и они лежат там, во views, но там, где мне надо (не в стандартном пути, генерируемом php artisan make:auth). На данный момент страница входа в закрытую зону сайтов в разработке — такая же открытая страница, как и многие другие потому маршрут к ней определяется так
Используй стандартные файлы шаблонов или переопредели методы.
Разные таблицы с разными данными для админов и заказчиков.
Зачем?
большинство того, что создаётся php artisan make:auth — лишнее
Это не повод лепить свой велик. В крайнем случае может удалить ненужные маршруты, контроллеры и представления.
Не в сети
Используй стандартные файлы шаблонов или переопредели методы.
Нет, мне нужны именно свои собственные, со своим дизайном и организованные в файловой системе так, как мне комфортно.
Потому что в этих таблицах разные данные для аутентификации. Всё, что нужно администраторам для аутентификации — это имя, email и пароль; в данном случае аутентификация осуществляется по email. Другое дело с таблицей аутентификационных данных для заказчиков. Там будет помимо имени заказчика и пароля также название сайта, алиас и номер заказа; аутентификация в данном случае осуществляется по номеру заказа, а не по имени заказчика.
Если все выше описанные задачи выполнимы стандартными средствами без кодизврата, то почему бы и нет. Но я пока сомневаюсь, что стандартные средства настолько гибки.
Изменено Gleb2708 (21.11.2017 18:08:13)
Не в сети
Страницы 1