Shane Matte: нужно делать новую миграцию (командой php artisan make:migration add_field_to_users_table --table="users"
Эта команда создаст новую миграцию с именем add_field_to_users_table в которую просто допишите нужные поля.
Затем нужно будет просто вызвать php artisan migrate чтобы применить эту миграцию.
Shane Matte: логично. Так как migration:refresh сначала откатывает все миграции, а затем накатывает их заного. У вас скорее всего после отката скрипт упал. Запустите php artisan migrate
Иван Воробей:
>Еще вопрос, стоит ли делать запрос авторизации сначала на API проекта, который будет отправлять его на API аккаунта, или делать напрямую
Тут зависит от того, какие токены и как будут использоваться.
>Как в это все вольется авторизация через соц. сети?
Можно сделать хранение "аккаунтов" на том же центральном сервисе авторизации, или вообще в репозитории.
Т.е схема такая:
- Авторизовываем пользователя (не важно каким способом)
- Если это новый юзер, то создаем аккаунт
- Генерируем ему токен и привязываем его к аккаунту.
- На всех сервисах по токену получаем аккаунт. Т.е по сути у нас будет 1 аккаунт в общем репозитории и сколько угодно аккаунтов в локальных (для каждого проекта).
Так вроде реализованно у ТМ. Т.е у нас есть основной аккаунт (логин\пароль\социалки) по которым происходит авторизация, и есть "локальные" аккаунты на хабре, тостере, фрилансим со своими профилями, которые привязанны к 1 основному аккаунту.
Иван Воробей: да, вы именно так и описали. Я просто сделал выжимку.
Свой сервер oauth я не использовал, но не вижу проблемы поставить его.
Если не хочется сильно заморациваться, можно использовать JWT для всей этой цепочки.
А можно еще проще...
- Сервер авторизации генерирует уникальный токен и кладет его в репозиторий
- После авторизации редиректимся на нужный сайт с этим токеном.
- Сайт проверяет токен в репозитории и если все ок, то авторизовывает пользователя стандартным ларавеловским Auth.
Тогда не нужно будет мудрить с постоянными запросами к репозиторию и писать свой драйвер для Auth.
Но тут проблема с отзывом авторизации, не получиться разом разлогинить пользователя на всех сервисах.
Можно так же добавить, что кроме автодополнения, через фасады непросто добраться до конкретной реализации класса. Не всегда понятно какая конкретно реализация используется, и где ее искать.
dk-web: так зачем Phone передавать в функцию? phones - это массив, его нужно просто взять из Request ($phones = $request->input('phones')) и затем через foreach ($phones as $phone) делать то, что вы делаете.
dk-web: Я обычно просто делаю в форме массивы:
user[fio]
phones[0]
И в контроллере просто забираю $request->input('user'), $request->input('phones') и работаю уже с отдельными массивами для каждой модели.
Но с таким подходом неудобно делать валидацию ошибок, и переводы ошибок, так как приходится прописывать кастомные правила.
zigen: push зальет все различия между локальной версией, и версией на гитхабе. Поэтому предварительно нужно сделать pull и смерджить. Затем можно спокойно пушить.
gadfi: именно. Зачем мне лишний головняк, когда я на фрилансе найду с десяток таких же как он, да еще и за меньшую стоимость? Параноить надо в меру. Есть подозрения что заказчик кинет? Или просто "а вдруг"?
Александр Шаповал: я бы забил на работу с человеком который "внезапно" начинает ставить какие-то условия, приглашать адвокатов и т.д. В итоге ни денег, ни работы у вас не будет.
Эта команда создаст новую миграцию с именем add_field_to_users_table в которую просто допишите нужные поля.
Затем нужно будет просто вызвать php artisan migrate чтобы применить эту миграцию.