Мультитенантность с одной базой данных полагается на столбец organization_id для обеспечения изоляции данных, но разработчики должны помнить о его включении в запросы. SQLFilter Doctrine может автоматизировать это, но его эффективность зависит от того, где он реализован и где пропущен. Фильтр организации намеренно отключен по умолчанию в конфигурации Doctrine, чтобы предотвратить проблемы с фикстурами, миграциями и скриптами восстановления. Он включается слушателем позже в жизненном цикле запроса, в частности, после брандмауэра, чтобы получить доступ к аутентифицированному пользователю и его организации.Однако у этого фильтра есть несколько слепых зон, где он не применяется или обходится. Консольные команды и обработчики очередей сообщений не получают выгоды от слушателя запросов, что означает, что они выполняются без включенного фильтра. Хотя это намеренно для таких задач, как пакетная обработка по всем арендаторам, это требует явного определения области видимости для команд, затрагивающих данные арендаторов. Панели администратора также намеренно исключены с помощью префиксов путей, чтобы они могли просматривать данные по всем арендаторам, что делает эти исключения критически важными для безопасности.Сущности, найденные в карте идентификации Doctrine до выполнения запроса, полностью обходят фильтр, поскольку SQL не генерируется. Аналогично, getReference() создает прокси без взаимодействия с базой данных, что означает, что фильтр не проверяется до тех пор, пока прокси не будет инициализирован. Нативные SQL-запросы, выполненные через DBAL, полностью игнорируют фильтры Doctrine, что представляет риск для функций отчетности и экспорта. Совместное наследование также может привести к пропуску фильтрации, если organization_id и маркерный интерфейс не находятся в корневой сущности. Несмотря на слухи, фильтры применяются к пакетным операторам DQL UPDATE и DELETE, но это охватывает только путь DQL. Тщательное автоматизированное тестирование имеет решающее значение для обеспечения надежности фильтра и выявления регрессий.