2016-02-10 2 views
1

В настоящее время я реализовал безопасность на уровне строк, где таблицы, которые должны быть защищены, имеют столбцы для прав владельца, группы и Unix-стиля.Отключить динамический выбор гибернации

Что происходит в каждом случае, когда мы запрашиваем сущность через спящий режим, мы добавляем пользовательский критерий, проверяющий, имеет ли пользователь доступ к данным. Этот настраиваемый критерий также добавляется к каждому create.Alias ​​(), чтобы убедиться, что контакт с другими таблицами также защищен.

Проблема заключается в том, что наша модель имеет несколько объектов с отношениями @manyToOne, и поскольку эти объекты автоматически выбираются, нет способа защитить вложенные объекты.

То, что я ищу способ либо:

  1. Сделать так, что только объекты добавлены через create.Alias ​​() выбираются

    ИЛИ

  2. Gain динамический контроль за тем, что выбрано спящим

Это, по-видимому, два способа, которые не означали бы переделанный код нашего проекта.

Это что-то, что можно сделать или есть какой-либо другой способ обеспечения безопасности на всем протяжении?

P.S: Никогда не возвращать вложенные объекты, к сожалению, невозможно, так как это необходимо на стороне клиента. Также мы попытались использовать max_fetch_depth 0, но, хотя в наших начальных запросах не были запрошены вложенные объекты, hibernate, похоже, выполняет несколько последующих запросов для завершения объекта.

ответ

1

Я на исследуемом, но не используемом этапе, по существу, это для моего собственного проекта, и я считаю, что filters - это то, что вы хотите. Если я правильно понимаю документацию, вы определяете фильтр вместе с вашей схемой, включаете его и передаете ему параметры программно, когда вы открываете сеанс, и в течение всего сеанса Hibernate будет притворяться объектами, которые не пропускают фильтр don не существует. Помимо обеспечения безопасности на основе отношений, это также устранит необходимость вручную добавлять проверки безопасности на каждый запрос.

+0

Благодарим вас за ответ. Мы смотрели в фильтр, к сожалению, кажется, что для этого потребуется добавить такой фильтр для всех текущих отношений и будущих. Это будет означать, что если будущий программист добавит несколько других моделей и забудет включить фильтр, объект не будет защищен. Это кажется довольно рискованным. Также в настоящее время наши запросы к базе данных почти все перегруппированы в общий «сервисный» класс, поэтому добавление безопасности для каждого запроса не является проблемой. – jemag

+0

Я не собираюсь врать, у меня действительно нет идей в этой ситуации, и я думаю, что фильтры спячки могут быть возможны как временное решение. Проблема состоит в том, что кажется, что я не могу отфильтровать Entity с использованием свойств Entity ManyToOne. Если вам удалось найти способ обойти это в вашем собственном проекте, вот еще одно сообщение stackoverflow, которое я сделал по этой проблеме: http://stackoverflow.com/questions/35437164/hibernate-manytoone-filter-on-base-entity – jemag

+0

@jemag Я работаю над этим. Фильтры все чаще бросаются в глаза мне, как полузасушливая реализация идеи, которая действительно заслуживает большего. Они чрезвычайно ограничены как в области применения, так и в области доступных свойств для фильтрации. – Douglas

Смежные вопросы