Лучшая практика в приложении Laravel с использованием 2 разных учетных записей

#php #laravel

#php #laravel

Вопрос:

Я пытаюсь создать приложение Laravel, в котором пользователь может быть аутентифицирован 2 различными способами.

  1. Аутентификация пользователя по умолчанию eloquent
  2. API, который может возвращать true или false , если учетные данные пользователя действительны.

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

Комментарии:

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

2. @Mjh Как я прочитал в документации Laravel, поставщик обрабатывает аутентификацию.. Здесь я могу ошибаться, но я также не могу найти способ обрабатывать аутентификацию извне «способом Laravel».

3. Вы могли бы использовать laravel.com/docs/master/passport однако это сделает больше, чем просто вернет логическое значение. Кроме того, вы правы, для аутентификации пользователя используются охранники и (пользовательские) провайдеры, но, пожалуйста, не путайте провайдера с поставщиком услуг.

4. @Chris можете ли вы опубликовать ссылку на то, что именно вы прочитали? Поставщик — это концепция, это способ предоставления сервиса путем подключения его к внутренним конструкциям Laravel. Это не имеет никакого отношения к выполнению работы. Для аутентификации пользователя в Laravel вы передаете экземпляр IlluminateContractsAuthAuthenticatable в Auth::login() . Это означает следующее: модель по умолчанию ( AppUser ) реализует вышеупомянутый контракт. Как только модель загружена (через Eloquent, используя имя пользователя пароль), она передается Auth::login(); методу. Я могу дополнить ответ, если это то, что вам нужно.

5. @Mjh Защитником в этом случае было бы что-то связывающее SessionGuard , а провайдером было бы что-то вроде EloquentUserProvider . Если вы посмотрите в свой config/auth.php , вы увидите, что используется именно эта терминология. Вы абсолютно правы, хотя это не то, что следует путать с ServiceProvider .