Как разнести приложение по поддоменам, сохранив на всех частях одну аутентификацию?

Question

[mrSeller]

Сам не совсем понимаю как задать вопрос, поэтому изначально он может быть непонятен.

У меня есть приложение, которое состоит из двух лендингов, личного кабинета и админской части.
Хотелось бы отделить каждый лендинг в отдельные приложения на отдельные поддомены, личный кабинет так же, и админку тоже. А главную оставить как общую площадку для различного контента.

Но я не совсем понимаю как это сделать.
Например, везде должна быть одна авторизация, т.е. если пользователь зашел в ЛК, то и в лендингах у него тоже были соответствующие изменения с помощью Auth. И как-то не догоняю, как разные приложения будут использовать одну авторизацию (не силен в терминологии).

И оффтоп.
В нем (приложении) есть 3 типа юзеров: 1 - покупатели, 2 - поставщики, 3 - администрация.
Правильно ли использовать одну таблицу для всех?
Для различия между 1 и 2 я использую столбец type и role_id=0, а для администраторов используется role_id выше 0.
Но мне кажется такая система немного запутанной и сложной для дальнейшего усовершенствования.

Answer 1

[Евгений Вольф]

Как разнести приложение по поддоменам, сохранив на всех частях одну аутентификацию?

Подозреваю, что для этого самым простым решением будет использовать использовать одну и ту же базу, в которой эти пользователи лежат. Например, так. Прописать отдельное подключение до базы с пользователями можно как в модели, так и при использовании DB::.

Второй вариант, более сложный - проксировать данные при их обновлении либо на уровне самой БД (не все БД такое умеют к сожалению, синхронизировать отдельные таблицы в режиме "мульти-мастер"), либо с помощью программы работающей в фоновом режиме, которая будет каждый N-секунд/минут/часов/etc проверять данные в обоих БД и синхронизировать их.

Правильно ли использовать одну таблицу для всех?

А в чем Вы видите потенциальную проблему такого подхода?

Но мне кажется такая система немного запутанной и сложной для дальнейшего усовершенствования.

Лично мне, сложной она не кажется и особо запутанной тоже. Другой вопрос в том, что в Laravel есть уже готовая система и авторизации, и аутентификации и т.д., в т.ч. различные механизмы схожие с теми, что Вы обозначили как "права доступа".

Comments

[mrSeller]

По первому вопросу ясно куда копать, спасибо.

А вот по второму.
Я попробовал изучить и понять эту готовую систему, но как-то сложновато (я не очень в бекенде плаваю).
Потому решил делать ручками все, т.к. денег лишних на хорошего разработчика пока не водится.
И вот когда смогу нанять команду разрабов, хочу чтоб не было насрано в коде и логике)

В планах будут еще типы пользователей, и в итоге у разных пользователь пустуют разные столбцы - это ничего, что, например, у меня 20-30 столбцов в таблице USERS, из которых 100% у каждого юзера заняты 5-10, а остальные используются только у определенных типов юзеров?

[Евгений Вольф]

это ничего, что, например, у меня 20-30 столбцов в таблице USERS, из которых 100% у каждого юзера заняты 5-10, а остальные используются только у определенных типов юзеров?

Не могу сказать, насколько это критично применимо конкретно к пользователям и конкретно в Вашем случае, но обычно это стандартная практика, точнее одна из двух подобных практик:
1. У Вас какое-то "вменяемое" количество полей/столбцов (иногда их максимальное кол-во ограничивается движком БД) и Вы заполняете нужные поля данными. Само собой разумеется, что не все и всегда данные могут быть заполнены... по этому, во многих БД существует флаг (опция), позволяющая (разрешающая) полю иметь значение NULL
2. У Вас динамическое количество свойств и/или их количество - неизвестно. В этом случае создают таблицу в которой хранятся базовые свойства (на примере пользователей - это может быть, например: ID, логин, пароль, e-mail и т.п.) а динамические поля - хранятся в отдельной таблице (а их значения в 3-ей). Получается, в некоторой степени "сложная" связь, но за то, Вы можете "крутить" эти данные как угодно и выстаивать в любом порядке.

Какой из подходов "лучше" - зависит исключительно от ситуации, движка БД и десятков других факторов. Если пользователей не очень много (т.е. их кол-во не измеряется десяткам и сотнями тысяч) - думаю, ничего особо страшного не случиться, если какие-то поля заполняются "там", другие "тут" и т.д. Вопрос только в том, что бы Вам/кому-то_ещё потом это было удобно поддерживать, т.е. что бы "подключение ещё одного сервиса/проекта/сайта" и т.д. - либо не предусматривалось изначально (или было предусмотрено не в режиме "подключил/отключил", как жесткий диск на сервере) и не вело за собой необходимость остановки базы и тотальной переработки кода...

P.S. Постарался объяснить "попроще", но если что-то не понятно, не стесняйтесь, спрашивайте :)

[mrSeller]

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

Есть users с базовым набором полей: id, name, phone, password, role_id
Есть fields и там такой набор: id, name, user_id (если юзер заполнил это поле), role_id (чтобы ограничивать отображение инпутов для разных групп пользователей).
Есть values, и там id, value, field_id, ..?

Около 6-7 раз писал/переписывал, пытаясь понять, как завязать логику между таблицами)
Примерно так получается?

[Евгений Вольф]

mrSeller, да, очень похоже на то, о чем я говорил. От себя, я бы пожалуй вот чего:
с пользователями - думаю всё понятно, с ними проще всего

таблица "fields" - там содержится набор уникальных, примерно такого содержания:
1. ID
2. title - название самого поля
3. Какие-то ещё поля по мере необходимости, иногда бывает нужно name/machine_name и т.д.

"values" - сами значения, непосредственно, минимальное содержимое таблицы выглядит примерно так:
1. ID
2. field_id (предыдущая таблица, ID оттуда)
3. value - значеие непосредсвенно
4. user_id - ID пользователя

Примерно так.

Потом мы всё это дело, например "джойним", как нам нужно или "вертим" любым другим удобным образом :)

[mrSeller]

Евгений Вольф, круто, спасибо большое)

[Евгений Вольф]

mrSeller, не за что, обращайтесь! :)

[mrSeller]

Евгений Вольф, я таки не смог завязать поля между собой)
думал, что будет как в role__user простенько (относительно), но логика оказалась другой из-за того, что в Value еще надо заполнять поле value.

В ручную заполнять получается (проходясь по каждому полю в контроллере), но хотелось бы автоматии, чтобы создавать поля, а они сами заполнялись/изменялись.

Может в документации есть что-то? Я ничего такого не нашел в отношениях(

[Евгений Вольф]

mrSeller, что бы поля сами заполнялись - Вам нужно в форме передавать field_id и value. Таким образом можно будет вставить значение (или значения) одного/кадого поля.

[mrSeller]

Евгений Вольф, не совсем понятно как именно описать вставку полей
вот у меня приходит запрос, где все поля - кастомные, т.е. у всех id+значение.

Я накидал такой громоздкий код в контроллере:

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

[Евгений Вольф]

mrSeller, не совсем понимаю, зачем получать все кастомные поля? При сохранении формы, мы сохраняем сами значения... или там какой-то другой механизм?

[mrSeller]

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

[Евгений Вольф]

mrSeller, выводить поля - это 1 запрос, выводить все их значения (если нужно) - другой запрос. Вставлять значения определенных полей - это 1 запрос, никакие связи "прямые" при этом не нужны... Или я Вас не понимаю? :)

[mrSeller]

Евгений Вольф, хм. Мне так удобно, хотя может я и ошибаюсь

Answer 2

[vimes7]

Гуглите клиент-серверную архитектуру и web API. По сути у вас будет один API-сервер, к которому будут подключаться несколько клиентов.

По юзерам: почему нельзя просто создать таблицу roles со всеми типами пользователей и связать ее с users?