Динамическое соединение с базой данных Symfony 4 и пользователь FOS

Question

Используя Symfony 4, мы создаем приложение для нескольких клиентов, где у каждого клиента есть отдельная база данных. Базы данных клиентов создаются автоматически по требованию при создании нового клиента. В ходе этого процесса мы создаем уникальный дополнительный файл.env (для конкретного клиента), в котором хранятся учетные данные подключения к базе данных.

У нас есть 2x подключение к базе данных и 2x менеджеры сущностей 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?

Answer 1

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

Установка 512 (должно быть достаточно) для включения перед SessionListener