Spring Security + JSF ROLE-ориентированный рендеринг компонентов страницы (ссылки и т. Д.), Лучшие практики - PullRequest
Новая
       20

Spring Security + JSF ROLE-ориентированный рендеринг компонентов страницы (ссылки и т. Д.), Лучшие практики

4 голосов
/ 21 марта 2012

Usign JSF + Spring Security.

Решение 1 - ориентированный на пользовательский интерфейс:
JSF страница отображает панель с пользователями, если аутентифицированное лицо имеет только права доступа ROLE_ADMIN. 

<p:panel rendered="#{facesContext.externalContext.isUserInRole('ROLE_ADMIN')}">
...

Решение 2 - бэкэнд-ориентированный (аннотировать соответствующий метод DAO): 

@Transactional
@PreAuthorize("hasRole('ROLE_ADMIN')")
public List<User> getUsers() {
    return sessionFactory.getCurrentSession().createCriteria(User.class)
            .list();
}

Резюме:
ПохожеАтрибут JSF rendered не является гибким решением, а аннотированные методы DAO не удобны для пользователя из-за перенаправления на 403.

Что такое изящное решение, которое позволяет мне НЕ отображать панель или ссылку, чтоне соответствуют конкретным органам власти?

Ответы [ 2 ]

9 голосов
/ 21 марта 2012

Вы не хотите показывать панели конечного пользователя или какие-либо функции, которые конечному пользователю не разрешено просматривать / использовать в любом случае. Это приведет только к общей путанице и разочарованию. Таким образом, проверка роли в атрибуте rendered - это путь.

Выражение может быть упрощено только в такой форме: 

<p:panel rendered="#{request.isUserInRole('ROLE_ADMIN')}">

ExternalContext#isUserInRole() делегирует HttpServletRequest#isUserInRole(), но HttpServletRequest сам по себе также присутствует в области видимости EL как #{request}.

1 голос
/ 21 марта 2012

Spring Security, в зависимости от того, как он настроен, вернет 403 или перенаправит в случае, если пользователь не авторизован для доступа к определенному ресурсу.

Решение 1 - это подходящий способ сделать то, что вы пытаетесьчтобы достичь, но вы по сути создаете зависимость между FacesContext и вашим взглядом, что я считаю плохой практикой.Лучшим решением было бы заключить эту логику авторизации в свойство управляемого компонента.Преимущество этого состоит в том, что ваше представление больше не зависит от вашей реализации авторизации, и ваш управляемый компонент теперь соответствующим образом содержит эту зависимость.

...