Используя Symfony 4, мы создаем многопользовательское приложение, где у каждого клиента есть выделенная база данных. Базы данных клиентов создаются автоматически по запросу при создании нового клиента. Во время этого процесса мы создаем уникальный дополнительный файл .env (специфичный для клиента), который содержит учетные данные для подключения к базе данных.
У нас есть 2 соединения с базой данных и 2 менеджера объектов - common и customer. Фактически, по умолчанию используется менеджер сущностей customer. Очевидно, что у менеджера сущностей customer сначала нет правильных параметров подключения.
Мы загружаем дополнительный файл .env соответственно (например, на основе домена) по запросу ядра и соответственно устанавливаем соединение customer и диспетчер сущностей:
$connection = $this->entityManager->getConnection();
$connection->close();
$reflectionConn = new \ReflectionObject($connection);
$reflectionParams = $reflectionConn->getProperty('params');
$reflectionParams->setAccessible(true);
$params = $reflectionParams->getValue($connection);
$params['dbname'] = $database; // read from the customer specific .env
$params['user'] = $username; // read from the customer specific .env
$params['password'] = $password; // read from the customer specific .env
$reflectionParams->setValue($connection, $params);
$reflectionParams->setAccessible(false);
$this->entityManager = $this->entityManager->create(
$this->entityManager->getConnection(),
$this->entityManager->getConfiguration()
);
Это прекрасно работает!
Проблема в контексте безопасности (?) - мы используем FosUserBundle, который не может авторизовать пользователей. Я предполагаю, что приведенного выше кода недостаточно, чтобы повлиять на контекст безопасности.
Каким будет правильный способ достичь цели динамического подключения к базе данных + авторизации пользователя с использованием стандартного FosUserBundle?






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