Deadbolt 2: Полностью контролировать ограничения с помощью настроек БД

Привет

Я хочу или, скорее, должен контролировать ограничения для некоторых действий и контроллеров через настройки базы данных, как лучше всего выполнить эту работу?

Какова моя цель: мне нужно создать решение, в котором будет много групп пользователей (хранящихся в БД) и они будут полностью динамическими (создаются и удаляются из админки). Разрешения должны быть унаследованы для подгрупп, поэтому, если у пользователя есть роль EditorsChief, он также может выполнять действия, разрешенные для всех Editor. Я не могу просто аннотировать действие/контроллер с помощью @Restrict({"EditorsChief", "Editor"}), потому что они не существуют (должны создаваться на лету с помощью панели администратора).

Моя первая мысль — использовать @Dynamic контроллер и группировать ограничения с отдельными обработчиками, что, конечно, требует жесткого кодирования некоторых из них. Это не так уж и плохо - при некотором внимании можно установить неплохую схему, (т.е. назвав обработчики по соглашению: handlerControllerAction, handlerControllerOtherAction...

Что ты думаешь ? Я иду в правильном направлении?


java authorization playframework playframework-2.0 deadbolt
person biesior    schedule 25.05.2012    source источник
comment
звучит как Drupal, но намного быстрее ;-) Что касается вашего вопроса, нового для Play, исходящего от Scalatra, где каждый маршрут имеет перехватчики до и после, а также beforeAll для всего приложения. Корреляция игры — это интерфейс глобальных настроек (я полагаю); может быть, использовать это с хранилищем значений ключа Redis для быстрого доступа к модели разрешений? Вам так или иначе придется выполнять оперативный поиск, просто вопрос о том, где вы реализуете безопасность, напрямую на контроллерах (проще для понимания) или неявно через глобальный фильтр   -  person virtualeyes    schedule 26.05.2012
comment
@virtualeyes, де-факто deadbolt является модулем авторизации, поэтому мне не нужно создавать решение. Скорее, это вопрос к тому, кто имел опыт работы с подобной схемой, может ли он поделиться своими мыслями :) Я просто проверяю ее возможности и должен подтвердить, что моя идея идет правильным путем. Кстати, Redis может быть хорошим усилителем производительности, однако я не ожидаю такого огромного трафика, что разрешение роли может стать узким местом, однако... хм... кэширование в целом неплохая идея :)   -  person biesior    schedule 26.05.2012

Ответы (1)


arrow_upward
2
arrow_downward

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

Затем в панели администратора вы можете связать эти имена с группами, ролями или чем-то еще и выполнять управление на основе этого. Это было бы, по моему мнению, отношением «один ко многим» в БД.

Дайте мне знать, если мне нужно объяснить это более подробно.

Стив (автор Deadbolt)

person Steve Chaloner    schedule 31.05.2012
comment
Стив, вам не нужно было упоминать, кто вы такой :) Ваше предложение довольно близко к моим мыслям, поэтому после нескольких тестов с предоставленными наборами образцов у меня в настоящее время есть общее видение и план реализации, но мне нужно потратить некоторое время на другие задачи. , так что я задам еще вопрос в случае каких-либо проблем. Спасибо - person biesior; 31.05.2012