Скрыть и показать или переключить панели и компоненты на основе пользователя и контекста

Question

Я разрабатываю приложение для калитки (в настоящее время использую калитку 1.5), которое собирается получить функцию, похожую на блог.Пользователи могут публиковать материалы или отмечать определенные бизнес-объекты как общедоступные, а другие пользователи могут комментировать их.Только владелец может редактировать эти бизнес-объекты или сообщения.Я знаю, что есть несколько фреймворков, предоставляющих функции скрытия / показа или переключения панели на основе текущего пользователя, но есть ли что-нибудь, что можно использовать для этого не только на основе пользователя, но и на основе контекста?Я знаю, что мне придется предоставить свою бизнес-логику, но я бы предпочел пропустить весь повторяющийся шаблонный код, так что даже подход, управляемый AOP, мог бы сработать, но так как я никогда раньше не работал с этим, я неt знаю.

Редактировать : Подробнее о сценарии:

В приложении любой (вошедший в систему) пользователь может ввести, скажем, рецепты, которые он может пометить как общедоступные (может быть прочитан кем угодно) или частным (может быть прочитан только им самим).Любой зарегистрированный пользователь может комментировать любой публичный рецепт (публичный или приватный).Личные комментарии могут прочитать только комментатор и владелец рецепта.Только владелец может редактировать рецепт.Только комментатор может редактировать свои комментарии.Только владелец рецепта или комментатор могут удалять комментарии.В общем, я просто ищу идею расширить классическую модель безопасности на основе ролей с помощью роли на основе контекста («владелец»), и, написав это, кажется, что единственным преимуществом для этого будет то, что я бы предпочелрешение, основанное на фреймворке, который хорошо интегрируется с калиткой (или даже с такой, где интеграция уже обеспечивается wicketstuff).

Answer 1

Если вам нужна структура безопасности, которая поддерживает авторизацию на основе экземпляров, вы можете взглянуть на ACL Spring Security .

Но если вы не хотите создавать что-то, скажем,гибкая и универсальная, как файловая система Unix, я не думаю, что такое решение необходимо.

В любом случае, чтобы «интегрировать» любое решение, которое вы выберете, в страницы Wicket, вы можете сделать что-то столь же простое, как переопределение.метод onConfigure () (на страницах или компонентах) для проверки прав пользователя и установки видимых / невидимых объектов, включаемых / отключаемых по мере необходимости.

@Override
public void onConfigure() {
    boolean isAuthor = getCurrentUser().equals(post.getAuthor());
    deleteButton.isVisible(isAuthor);
    editLink.isEnabled(isAuthor);
}