Symfony несколько баз данных для входа в систему клиента
Я разрабатываю веб-приложение в Symfony2. Веб-сайт должен иметь базу данных для каждого клиента. Моя идея состояла в том, чтобы сделать основную базу данных с информацией обо всех организациях и их базах данных. Но сейчас у меня проблемы.
У каждого клиента есть свои пользователи. Эта информация должна храниться в собственной базе данных. Поэтому, на мой взгляд, у каждого клиента должна быть своя страница входа. Теперь я начал с добавления префикса, чтобы узнать, каким клиентом вы являетесь: example.com/ndomclient enj/ -> controllers. Дело в том, что вам не разрешено устанавливать параметр в вашем маршруте для страницы входа в Symfony! Итак, как мне убедиться, что у каждого клиента есть отдельная страница входа?
Другое дело безопасность. Каков наилучший способ убедиться, что пользователь не может изменить параметр маршрута на другой клиент и получить доступ?
Я искал руководства в Интернете, чтобы сделать то, что мне нужно сделать. Но я не могу найти надежных способов для Symfony2 .. В основном это половина решения, например, просто переключение между базами данных через сервис. Если есть еще одна php-фреймворк, которая делает все это намного лучше, я бы определенно подумал и об этом.
Я надеюсь, что вы, ребята, можете дать мне несколько советов. Заранее спасибо.
Решение
у вас есть структура базы данных с несколькими экземплярами, где каждый клиент имеет свою отдельную базу данных, как насчет использования структур с несколькими теннантами, где все клиенты хранятся в одной базе данных, а настройка веб-сайта выполняется на основе идентификатора клиента, таким образом, нет необходимости отдельная страница входа или переключение базы данных. если это не значительное и существенное изменение в структуре проекта, вы можете рассмотреть это. будет дешевле
если невозможно изменить структуру проекта, то как насчет использования поддоменов вместо URL-слагов? company.example.com на месте example.com/company
Другие решения
Как я понимаю, у вас есть 2 варианта
оформление базы данных с несколькими экземплярами
(что-то вроде «облачный» вариант я предполагаю?)
1: Используйте поддомен для каждого клиента, где вы развертываете другое приложение, ориентированное на управление этой базой данных, тогда как в вашем основном приложении генерируйте структуру каталогов, развертывайте приложение symfony и управляйте генерацией зон vhost и dns.
2: ради этого объяснения мы будем использовать это:
Клиенты = каждый клиент-владелец базы данных.
Пользователи = клиенты клиента.
Каждый клиент использует одну и ту же сущность пользователя.
Вы упомянули, что знаете, как переключать базы данных, затем в своей базе данных храните информацию о своих клиентах, включая учетные данные базы данных (user, pass, db и т. Д.), И сохраняете информацию о пользователях в базе данных соответствующего клиента.
Теперь, когда вы звоните example.com/{client} вы смотрите в своей базе данных для этого {client} загрузить информацию о базе данных для этого клиента, переключить базу данных и позволить пользователю войти в систему и сделать свое дело. Очевидно, что при последующих запросах лучше хранить учетные данные базы данных в сеансе.
Теперь вы должны спросить:
Q: что если пользователь изменит {client} после входа в систему?
A: Symfony выходит из системы пользователя.
или, по крайней мере, это то, что документация говорит.
Как только пользователь вошел в систему, весь объект пользователя сериализуется в
сессия. При следующем запросе объект User десериализуется.
Затем значение свойства id используется для повторного запроса свежего
Пользовательский объект из базы данных. Наконец, новый объект User
по сравнению с десериализованным объектом User, чтобы убедиться, что они
представлять того же пользователя. Например, если имя пользователя на 2 пользователя
объекты не совпадают по какой-то причине, тогда пользователь будет зарегистрирован
из соображений безопасности.
Q: Но что делать, если у пользователя такой же пользователь / пароль другого {client}?
A: помните, что также идентификатор сериализуется, но если вы также хотите добавить еще один уровень безопасности, просто добавьте поле в сущности пользователя, где оно ссылается на то, к какому клиенту он принадлежит (в своей собственной базе данных), и сериализуйте его.