Ограничение запрашиваемых данных гибернации на основе группы-владельца пользователя

Question

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

Я использую JBossAS7 с Hibernate 4.x.

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

Я предполагаю, что должно быть стандартное, безопасное решение для этого, возможно, вокруг доменов безопасности или сеансов гибернации?Мысли?Заранее спасибо.

Answer 1

Похоже, вы создаете «мультитенантное приложение». В настоящий момент поддержка многопользовательского режима в Hibernate довольно ограничена, поскольку недавно была завершена функция request 5697 в 4.0.0.Alpha2. Обратите внимание, что этот запрос функции не касается добавления столбцов дискриминатора арендатора в сущностях, которые, согласно обсуждению в JIRA, будут поступать в 4.0.0.Alpha3 или 4.1.0 (собирается JIRA). На данный момент вы можете хранить данные, относящиеся к различным арендаторам, в разных базах данных или схемах.

Вы также можете прочитать это сообщение в блоге о различных вариантах достижения многопользовательского режима в Hibernate; это довольно старый процесс по сравнению с работой, выполненной в HHH-5697, и не обсуждается, как можно создать мультитенантное приложение со столбцами дискриминатора арендатора в модели сущностей.

Answer 2

Я не уверен ни в каком стандарте, но работал на двух системах, где это было важно. Эти устаревшие инструменты, такие как Hibernate и наше использование J2EE.

Во всех системах, над которыми я работал, нам приходилось кодировать это самостоятельно - используя компанию как часть наших ключей в запросах.

Одна возможность - это совершенно разные "все, что ваша база данных называет своим разделом" для каждого клиента. (Схема, если вы в Oracle). Звучит сложнее, но гарантирует изоляцию между компаниями, а также позволяет управлять масштабированием или новой / удаленной компанией. На моем предыдущем месте работы я помню, что юристы нервничали, если кто-то упоминал, что они хранят в одной таблице более одной компании - так, чтобы они были довольны.

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

Edit: ответ Vineet выше, кажется, хорошо его охватывает Это область, на которую мне нужно взглянуть больше. Вероятно, у нас слишком много устаревшего кода, чтобы его можно было изменить.