2016-08-30 11 views
3

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

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

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

также Какой лучший сценарий?

  1. пройти аутентификацию, получить токен jwt.
  2. отправьте токен с каждым запросом.
  3. по каждому запросу проверить токен, проверить субдомен, подключиться к соответствующему арендатору db, выполнить запрос.

Это хороший подход? что мне делать с проблемой таблицы пользователей? ThnQ

+0

«хранить его внутри жильцов дб затруднит для проверки подлинности всех пользователей» Почему хотите ли вы это сделать? –

+0

Возможно, я не делал этого ясно ... если я храню его у арендаторов db, когда пользователь регистрируется в первый раз, не указывая, какой арендатор. как я узнаю, с какой db аутентифицироваться? – Sherif

+1

Либо сделайте их явно указанным арендатором, используя идентификаторы пользователей, которые выглядят как электронные письма (например, [email protected]), или неявно определяют арендатора, просмотрев доменное имя, которое обслуживало запрос. В любом случае вы хотите, чтобы ваши идентификаторы пользователей были уникальными в каждом арендаторе, а не уникальным для всех. I.e., если кто-то настраивает bid-идентификатор пользователя внутри арендатора №1, это не должно препятствовать тому, чтобы кто-то другой использовал бэнд-идентификатор userid у арендатора №2. –

ответ

0

Я могу предложить третий вариант. Имейте пользователя как в арендаторе, так и в главном db. Затем вы можете создать процедуру для обновления основного db, когда пользователь изменяет db арендатора (или наоборот).

Кроме того, я не знаю моделей в Laravel, но MySQL не имеет проблем с перекрестными базами данных JOIN.

+0

Я загляну в кросс-db-соединения MYSQL, но я стараюсь избегать дублирования данных, я думаю, что это плохая практика. – Sherif

+0

Это зависит. В многопользовательском приложении иногда лучше иметь несколько данных для повышения производительности. Что делать, если одного сервера будет недостаточно? Вы можете просто разделить базы данных арендаторов между несколькими серверами db, но вам все равно нужны все они в основной базе данных. –

0

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

Sharing поток аутентификации

  1. Пользователь попадает в суб-домен для входа для приложения
  2. учетные данные пользователя будут отправлены к применению
  3. Перед передачи учетных данных для проверки подлинности, решить базу данных для аутентификации пользователя, основанный на поддомен, из которого пришел пользователь.
  4. имени базы данных Pass, пользовательские учетные данные в систему аутентификации
  5. Authentication системы запросов конкретных баз данных и аутентификации пользователей
  6. Генерация сеанс