Как сделать авторизацию по логину и email?

Question

[Максим]

Как сделать, чтобы можно было авторизоваться как по логину, так и по email?
laravel 6.x

use AuthenticatesUsers;

    protected $redirectTo = RouteServiceProvider::HOME;

    public function __construct()
    {
        $this->middleware('guest')->except('logout');
    }

Answer 1

[Константин Б.]

Этот кусок кода ты сюда бросил в качестве примера "я пытался, но не получилось"?

Ну давай раскинем мозгами вместе. У тебя есть трейт AuthenticatesUsers
Из него к себе в контроллер тебе нужно скопировать метод username. Сейчас он такой

public function username()
    {
        return 'email';
    }

Твоя задача проверить что тебе пришло с формы, логин или email
Для этого тебе подойдет метод filter_var($string, FILTER_VALIDATE_EMAIL) который уже есть в PHP
$string это то что ты отослал с формы, в зависимости от того что это ты должен вернуть название по какому полю производить поиск пользователя в таблице - email или name

public function username()
    {
        // вот тут ты должен выполнить проверку что пришло и в зависимости от этого сделать return название столбца email или name
    }

Дальше сам!

Comments

[Максим]

не) я скинул, чтобы видно было версию, я даже представить не могу, как сделать

думал так, но не работает

if (Auth::attempt(['email' => $name,'name' => $name, 'password' => $password], $remember)) {
}

[kafkiansky]

Максим, вам же написали. Проверяйте, что пришёл не емейл и ставьте username, иначе email

[Analka]

kafkiansky, а что подставить вместо string? в документации вообще ничего не написано по этому поводу

[Константин Б.]

Analka, вместо string? В валидации что-ли?

[jazzus]

Константин Б., в твоем говнопримере string) Когда начнешь читать документацию?

[Константин Б.]

jazzus, в моем примере $string вовсе нет от Laravel)) Внезапно да, оказывается можно использовать и ванильные методы!

[Константин Б.]

jazzus, а то что человек бревно, не мои проблемы

[jazzus]

Константин Б., зачем ты оскорбляешь людей? Тем более, когда сам написал глупость. В ларавел есть валидация, методы реквеста c хелперами и даже пример кастомного логина. Этого зауши, чтобы сделать свою авторизацию. Зачем здесь твои ванильные методы для меня загадка

[Константин Б.]

jazzus, причём тут вообще валидация? Что я такого сверхъестественного написал от того что ты мне сейчас пытаешься втереть? Вот ты реально пытаешься придумать какой-то костыль из валидации и прочей хрени в твоей безумной голове. Я написал человеку решение буквально в одну строку, а ты предлагаешь какую-то ахинею

[jazzus]

Константин Б., зачем FILTER_VALIDATE_EMAIL?

[Константин Б.]

jazzus, затем чтобы отличить строку от email и с зависимости оттого провести вход по логину если это строка или email адресу если это email

[jazzus]

Константин Б., тебя в этом варианте ничего не напрягает?

[Константин Б.]

jazzus, а что меня должно в нем напречь?

[NubasLol]

jazzus, Если буквально понимать вопрос, то поле в запросе может бытьи email и строка.

И это не разные параметры, а один.

[jazzus]

NubasLol, даже если с одного поля – хотя это новые условя, не нужно делать валидацию?

[NubasLol]

jazzus, причему тут валидация? Как она поможет отделить email от строки?

[jazzus]

NubasLol, да там куча вариантов. Как минимум чтобы проверить есть такой емейл если емейл. Обычно на тестах туча вариаций, связанных с валидацией. Плюс как обслуживать все эти изварщения, в смысле сообщения и т.д. Ты тоже чтоли формы не валидируешь?)

[NubasLol]

jazzus, задача в другом, из одного поля формы может прийти как логин, так и email. Валидация нужна, кто спорит.

[jazzus]

NubasLol, эту задачу я слышу только от тебя

[NubasLol]

jazzus, причем в этой задаче единственной что надо проверить, так то что пришли строки.

Как минимум чтобы проверить есть такой емейл если емейл

Это делать не нужно. Это делает сам Laravel. И вообще не показывают ошибку валидации email в таком случае.

Ибо можно так узнать, какие email лежать у тебя в бд. Что ошибка.

[Константин Б.]

jazzus, никто не отменяет валидацию, она остаётся дефолтной. Просто мы не валидируем строку логина в запросе, а делаем это в самом запросе. А существование email адреса в момент входа - это оверхед, кроме тех случаев когда это нужно для вывода уведомления после ввода. В любом случае проверка как раз и будет в момент входа

[jazzus]

NubasLol, ты тестировал эти варианты? Я нет. Сомневаюсь, что Ларавел что-то там проверяет. Он проверяет судя по всему username, ожидая что там будет email.

[jazzus]

NubasLol, если изменять поля в дфеолте нужно переписывать валидацию и все обращение к username. Писать кастомные Rule и делать нужные проверки с возвратом сообщений об ошибках. или есть лучше способ?

[NubasLol]

jazzus, он извлекает модель по полю (email или еще что) а затем уже из модельки берет значение password и сверет хэш пароля с переданным

О каких тестах речь, не понимаю. Уж точно создатели ларавел протестили. Да и пользователи

Что ты собрался тестировать то?

[jazzus]

NubasLol, у меня >1000 строк кода в тестах для авторизации. Спам не спам и т.д. Не понимаю как можно обойтись проверкой выше. Рили работает?)

[jazzus]

NubasLol, даже если в одном поле (хотя в задаче такого нет) – какой смысл делать вне валидации? Делай user rule, required if возвращай ошибки через message, тестируй через jsonValidationErrors. Какая причина не использовать все эти решения?

[NubasLol]

jazzus, причина в том, что это лишние действия, которые не нeжны. Спам не спам, к логину никак не относится.

Вообще не понимаю, что ты собрался валидировать. Приведи пример.

Ведь все из коробки работает как надо

[NubasLol]

jazzus,

у меня >1000 строк кода в тестах для авторизации

Чивоо? это слишком много

[Константин Б.]

NubasLol, да он не понимает о чем говорит сам

public function username()
{
        $login = request()->name;
        return filter_var($login, FILTER_VALIDATE_EMAIL)
            ? 'email'
            : 'name';
}

/**
*  Нужна валидация? Нет проблем 
*/
    protected function validateLogin(Request $request)
    {
        $loginRules = 'required|string';

        if ($this->username() === 'email') {
                $loginRules = 'required|email|exist:users'
        }

        $this->validate($request, [
            $this->username() => $loginRules,
            'password' => 'required|string',
        ]);
    }

[NubasLol]

Константин Б., так никто сейчас не делает, валидировать email на наличие в бд отдельно от пароля

[Константин Б.]

NubasLol, я как пример товарищу что если нужно, тогда делать

[jazzus]

Константин Б., NubasLol, признаю был не прав. Я имел ввиду сделать LoginRequest и подготовить данные в методе prepareForValidation. Но в Laravel username() используется в разных местах и его в любом случае менять поэтому определять емейл/логин в валидации смысла нет

[jazzus]

NubasLol,

Чивоо? это слишком много

У меня в процессе авторизации своя логика (типы юзеров, редиректы, уведомления и т.д.) плюс тех-моменты (капча, спам, типы запроса). Все покрыто тестами во всех вариациях т.к. я вначале пишу тесты, а потом фичу. Мне так удобней разрабатывать, дебажить и в тестах более полно формулирую тз и че хочу. И тесты не дадут схалявить и что-то забыть. Так по всему приложению. Правда код тоже в тестах дублирую и поэтому они длинные т.к. имхо ими так проще пользоваться.

[NubasLol]

jazzus, Писал я для 1 проекта такие тесты, покрывающие все.

Пришел к выводу, что все равно баги всплывают, а времени на тесты уходит большн чем на сам код

[jazzus]

NubasLol, ну я не пишу сейчас тесты для покрытия. Покрывать существующий функционал это гемор. Я делаю их для разработки. Вот смотри например сделать раздел где добавляются ссылки соцсетей с учетом что должны быть ссылки и только указанных соцсетей в полях под нужные языки с разным уровнем доступа для разных юзеров. Если без тестов делать это задалбаешься проверять руками. Различные авторизации заполнения и т.д. Там тьма вариантов, которые могут у юзера на проде всплыть. А так вначале напишешь тесты строчек на 300, потратишь 1,5ч т.к. они простые, однообразные и пишутся быстро (я пишу только Feature). Опишешь там все основные расклады - а юзеры бывают глупые или хитрые. И можешь к форме вообще не обращаться руками. Запускаешь тесты и разрабатываешь начиная с роута пока они не станут зеленые. Т.е. и разработку ускоряют и как детальное тз (пока пишешь куча новых идей приходит) и на будущее остаются для проверки. Ну и результат более качественный