Я пытаюсь создать приложение SaaS для многопользовательских арендаторов, и я знаю, что есть несколько подходов к этому, но я выбрал многозадачность, я думаю, что это будет больше всего подходит.лучший подход для приложения с несколькими арендаторами SaaS
поэтому я создаю db для каждого арендатора и храните таблицу арендаторов в главном db и подключайте пользователей к их соответствующей базе данных на основе субдомена.
сейчас моя проблема здесь, где хранить пользователей, в основном db? или арендатор db, хранение пользователей в основном db будет затруднять получение моделей, связанных с пользователем, в других db, но хранение их внутри арендаторов db затруднит аутентификацию для всех пользователей ...
также Какой лучший сценарий?
- пройти аутентификацию, получить токен jwt.
- отправьте токен с каждым запросом.
- по каждому запросу проверить токен, проверить субдомен, подключиться к соответствующему арендатору db, выполнить запрос.
Это хороший подход? что мне делать с проблемой таблицы пользователей? ThnQ
«хранить его внутри жильцов дб затруднит для проверки подлинности всех пользователей» Почему хотите ли вы это сделать? –
Возможно, я не делал этого ясно ... если я храню его у арендаторов db, когда пользователь регистрируется в первый раз, не указывая, какой арендатор. как я узнаю, с какой db аутентифицироваться? – Sherif
Либо сделайте их явно указанным арендатором, используя идентификаторы пользователей, которые выглядят как электронные письма (например, [email protected]), или неявно определяют арендатора, просмотрев доменное имя, которое обслуживало запрос. В любом случае вы хотите, чтобы ваши идентификаторы пользователей были уникальными в каждом арендаторе, а не уникальным для всех. I.e., если кто-то настраивает bid-идентификатор пользователя внутри арендатора №1, это не должно препятствовать тому, чтобы кто-то другой использовал бэнд-идентификатор userid у арендатора №2. –