Способы SaaS для доступа к нескольким базам данных и механизмам аутентификации пользователя с основной базой данных

Question

Я занимаюсь созданием приложения saas с основной базой данных для всех транзакций, а также базы пользователей и отдельных баз данных для каждого арендатора. Каждому арендатору предоставляется уникальный поддомен, и на основании этого правильная база данных указывается на арендатора. Веб-приложение построено с использованием php, и MySQL используется для хранения данных.

У меня есть пара проблем и для начала;

1. Когда пользователь посещает домашнюю страницу арендаторов (например, Sub.abc.com), будут доступны функции входа в систему. Поскольку пароль пользователя и пользовательская база находятся в основной базе данных, как я могу аутентифицировать пользователя? Это через отдельное соединение с базой данных для основной базы данных или через веб-apis? Каков наилучший способ?

2. Будут роли, созданные арендатором. Поэтому предположим, что персонал для конкретного арендатора извлекается, вызывая веб-api, и эта роль сохраняется в базе данных арендатора вместе с идентификатором пользователя. Правильно ли это, потому что нет прямого сопоставления внешнего ключа, а также после того, как пользователи будут извлечены, если я буду хранить в базе данных арендатора или просто держать его в памяти?

3. В случае, если владелец бизнеса хочет получить отчет о чем-то конкретном для каждой базы данных арендатора, каким будет лучший способ захватить все данные из каждой отдельной базы данных арендаторов?

4. Как мы можем использовать каждое использование базы данных арендаторов, хранить файлы и показывать в супер-админ?

Answer 1

как бы я аутентификации пользователя? Это через отдельное соединение с базой данных для основной базы данных или через веб-apis? Каков наилучший способ?

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

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

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

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

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

В случае, если владелец бизнеса хочет получить отчет о чем-то конкретном для каждой базы данных арендатора, что было бы лучшим способом захватить все данные из каждой отдельной базы данных арендаторов?

Это слишком широкое, чтобы ответить. Вы также должны быть здесь осторожны, потому что данные клиента могут быть вашими не сообщать!

Как мы можем использовать каждое использование базы данных арендаторов, хранить файлы и показывать в супер-админ?

Опять же, достаточно широк, но я предполагаю, что вы могли бы достичь чего-то вроде этого, запрашивая сервер MySQL для статистики базы данных на каждой клиентской базы данных и сделать то же самое для хранения файлов, запрашивая сервер, на файлы клиента ,

---

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

Answer 2

Будьте осторожны с вопросами «наилучшего способа» - это будет указывать на этот вопрос на то, чтобы быть вне темы, поскольку мнение основано.

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

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

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

Что вы подразумеваете под закрытым исходным кодом?

Если у меня могут быть API-интерфейсы аутентификации для извлечения данных из основной базы данных, как я могу разместить ее таким образом, что доступ к ней предоставляется только в приложении, а внешние стороны не могут получить к ней доступ? Позже мы должны иметь услуги, которые оказываются внешним пользователям. В этом случае лучше разоблачить это сейчас или позже работать над отдельными услугами? Каковы лучшие опрятные библиотеки веб-сервисов PHP, которые вы знаете, кроме NuSOAP?

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

Это правильно!Пользователи являются общими для всех реализаций, и они хранятся в основной базе данных, а не в отдельных банках-арендаторах. Роли, которые я имел в виду, для каждого арендатора, арендатор может создавать роли, которые входят в приложение арендатора, такое как биллинговая единица, учетные записи, стойка регистрации и т. д. Таким образом, эти user_id и role_id хранятся в базе данных арендатора. Вот почему я спросил, так как user_id напрямую не сопоставляется с пользовательской таблицей главной базы данных, если все в порядке.

Это слишком широкое, чтобы ответить. Вы также должны быть осторожны, потому что данные клиента могут быть не вашими, чтобы сообщить об этом!

Теперь давайте предположим, что супер администратор хочет знать роли каждого арендатора. В этом случае, как я могу получить данные из всех баз данных арендаторов? Используем ли мы представления для этого или с тех пор, как мы используем mysql, как я могу это достичь?

Опять же, достаточно широк, но я предполагаю, что вы могли бы достичь чего-то вроде этого, запрашивая сервер MySQL для статистики базы данных по каждой клиентской базе и сделать то же самое для хранения файлов, запрашивая сервер , на котором размещается файлы клиента.

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

Кроме того, для изображений сайта лучше хранить на жестком диске или в базе данных в виде BLOB? Конец дня нам нужно подумать о масштабируемости, а также о том, как изображения будут загружаться с меньшим потреблением полосы пропускания?