Многопользовательская многопользовательская база данных, один исходный код - PHP

Question

Многопользовательская многопользовательская база данных, один исходный код - PHP

0

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

Мы объединили наш исходный код для работы с любой базой данных, все исходные тексты одинаковы для всех клиентов.

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

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

Intially,

http://localhost/workspace/client/ → это URL-адрес, предоставленный клиенту, теперь я перенаправляю его на index.php с помощью htaccess и на основе клиента/я знал, какой клиент этот пакет будет использовать.

существуют разные клиенты, http://localhost/workspace/clien1/ http://localhost/workspace/clien2/ http://localhost/workspace/client3/

и так далее..

Теперь на странице index.php переадресовываем login.php, но конфигурация для DB не устанавливается в соответствии с клиентом.

если кто-нибудь справится с этим, пожалуйста, помогите мне.

Заранее спасибо.

Amey Damle 07 авг. 2018, в 12:25

Источник

0

Прежде чем вы сделаете перенаправление на login.php в вашем index.php вы должны установить cookie или переменную сеанса, определяющую, какая конфигурация БД должна использоваться для этого конкретного клиента. Затем login.php может прочитать переменную cookie / session и установить соответствующую конфигурацию БД.
IVO GELOV 07 авг. 2018, в 10:33
0

Привет GELOV, спасибо за ваш ответ. Я выбрал СЕССИЮ выше COOKIE в этом случае, имея, это частично работает. есть еще одно сомнение относительно длительности сеанса в любом веб-приложении? или запуск тысяч сеансов одновременно повлияет на производительность приложения? что будет лучшей практикой в этих случаях?
Amey Damle 10 авг. 2018, в 10:38
0

Поскольку сеансы хранятся на сервере - это концентрирует нагрузку. Фактическая загрузка будет зависеть от того, как вы храните свои сеансы (в файловой системе, через расширение igbinary PHP, в реляционной базе данных, в Redis и т. Д.). Если вы используете куки - вам не нужно ничего хранить на сервере, потому что cookie содержит (в зашифрованном виде) идентификатор пользователя и срок действия. Каждый запрос на ваш сервер будет получать обновленный файл cookie с новым временем истечения срока действия - так что вы можете принудительно повторно войти в систему, если вы получите файл cookie с истекшим временем.
IVO GELOV 10 авг. 2018, в 14:02

Показать ещё 1 комментарий

Теги:

php

mysql

multi-tenant

1 ответ

Ещё вопросы

Прежде чем вы сделаете перенаправление на login.php в вашем index.php вы должны установить cookie или переменную сеанса, определяющую, какая конфигурация БД должна использоваться для этого конкретного клиента. Затем login.php может прочитать переменную cookie / session и установить соответствующую конфигурацию БД.
Привет GELOV, спасибо за ваш ответ. Я выбрал СЕССИЮ выше COOKIE в этом случае, имея, это частично работает. есть еще одно сомнение относительно длительности сеанса в любом веб-приложении? или запуск тысяч сеансов одновременно повлияет на производительность приложения? что будет лучшей практикой в этих случаях?
Поскольку сеансы хранятся на сервере - это концентрирует нагрузку. Фактическая загрузка будет зависеть от того, как вы храните свои сеансы (в файловой системе, через расширение igbinary PHP, в реляционной базе данных, в Redis и т. Д.). Если вы используете куки - вам не нужно ничего хранить на сервере, потому что cookie содержит (в зашифрованном виде) идентификатор пользователя и срок действия. Каждый запрос на ваш сервер будет получать обновленный файл cookie с новым временем истечения срока действия - так что вы можете принудительно повторно войти в систему, если вы получите файл cookie с истекшим временем.

O. Jones · Answer 1 · 2018-08-07T08-02-00.000Z

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

Я предполагаю, что вы проверите аутентификацию своих пользователей, просмотрев их в общей базе данных, а затем проверив пароли с помощью password_verify() Когда вы знаете, что у вас есть действительный пользователь, вы можете

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

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

Но, совет: Создание новой базы данных для каждого клиента классно незаменимо. Что произойдет, если

ваш проект успешный, и вы обнаруживаете, что однажды добавили тысячи новых клиентов? В этот день вам придется добавить тысячу баз данных.
у вас есть 500 активных сеансов в какой-то момент? У каждого из них будет свое собственное соединение dbms, что делает схемы объединения пула php бесполезными. Объединение пулов имеет жизненно важное значение для хорошей производительности веб-приложений.
вам нужно выполнить некоторую операцию отчетности, которая охватывает всех клиентов? Вам придется запускать отчеты для каждого клиента отдельно и выяснить, как объединить их вместе в своей программе отчетов. Это сложно.

Хорошей практикой для многопользовательских онлайн-приложений является размещение идентификаторов пользователей или идентификаторов пользователя в каждой записи данных и использование предложений запроса, таких как WHERE customer_id =? (текущий клиент) для разделения пользователей данных пользователем.

Надеюсь, еще не слишком поздно пересмотреть свое дизайнерское решение для использования нескольких баз данных.

Привет O.Jones, спасибо за ваш ценный ответ. Ваше предположение было неверным. У нас нет общей базы данных для проверки пользователя. вместо этого, основываясь на URL-адресе, мы решаем, кем он является, и устанавливаем соединение с базой данных в сеансе. и эта работа. Я обсудю этот ответ со своей командой и посмотрю, что мы решим.