2016-09-14 3 views
0

Я создаю веб-сервис, используя Jersey + Jetty + Dropwizard + Hibernate.Установить роли в веб-службе Джерси

Скажем, у меня есть веб-сайт, как это:

@Path("/") 
@PermitAll 
public class Resource { 
    @RolesAllowed("user") 
    @GET 
    public String get() { return "GET"; } 


@RolesAllowed("admin") 
@POST 
public String post(String content) { return content; } 

@Path("sub") 
public SubResource getSubResource() { 
    return new SubResource(); 
} 
} 

Я знаю, что вы можете проверить роль пользователя с HttpServletRequest.isUserInRole.

Вопрос в том, как мне назначить роли для начала? Как Джерси знает, что вернуть для метода isUserInRole, или знает, как отфильтровывать людей от того, чтобы не попасть в конкретные ресурсы на основе их ролей?

У меня нет web.xml или webdefault.xml, поэтому определения должны быть сделаны в другом месте.

+0

Вы просмотрели документы для [Dropwizard Auth] (http://www.dropwizard.io/1.0.0/docs/manual/auth.html)? Он поддерживает Basic и OAuth. И есть сторонний [lib для JWT] (https://github.com/ToastShaman/dropwizard-auth-jwt). Вся эта роль обрабатывается каркасом. Если у вас нет и ни одно из этих решений не сработало для вас, и вы хотите взломать свой собственный –

ответ

0

Вы должны предоставить класс провайдера, который поддерживает аннотацию @RolesAllowed («admin»), а затем вам необходимо зарегистрировать класс провайдера в своем приложении. Обычно это делается в web.xml, но поскольку вы его не используете , вы должны предоставить его самостоятельно. Связанный пример можно найти: here

+0

, этот пример включает в себя создание настроек в файле web.xml, который я сказал, что у меня нет –

+0

. Как вы загружаете сержант трикотажа. Вы должны использовать какой-либо файл конфигурации или аннотацию (@webservlet). Вы должны загрузить его там. –

+0

У меня есть файл config.yml, и вся конфигурация ресурсов и т. Д. Выполняется с помощью класса конфигурации dropwizard –

0

Джерси использует свой собственный механизм для проверки ролей (см. интерфейс SecurityContext), однако, если он явно не установлен, он возвращается к аутентификации контейнера, который обычно реализуется с использованием JaaS. Если у вас есть web.xml, вы сможете настроить его там.

Снова повторная проверка подлинности выполняется по-разному. Если вы можете вручную зарегистрировать пользователя, например, иметь службу, которая может проверять имя/пароль, тогда вы можете реализовать ContainerRequestFilter, который заполнил бы контекст безопасности, который мог бы сделать аннотацию @RolesAllowed, чтобы просто работать.

Например:

обновляется на основе комментариев

метод Resouce журналов в пользователе:

@Path("some/login/path") 
public void login() { 
    String name = getUsernameFromRequest(); 
    String password = // like above 
    User user = loginService.login(name, password); 
    request.getSession().addAttribute("user", user); 
} 

Инициализировать контекст безопасности фильтра для всех запросов.

@Priority(Priorities.AUTHENTICATION) 
public class JerseySecurityContextFilter implements ContainerRequestFilter { 

    public void filter(final ContainerRequestContext context) throws IOException { 
    User user = getUserFromSession(); 
    if (user != null) { 
     // this sets security context for the rest of processing 
     // it should make @RolesAllowed work 
     context.setSecurityContext(new JerseySecurityContext(user); 
    } 
} 

final class JerseySecurityContext implements SecurityContext { 

    private final User user; 

    public JerseySecurityContext(final User user) { 
     this.user = user; 
    } 

    public boolean isUserInRole(final String roleName) { 
     return user.hasRole(roleName); 
    } 

    public Principal getUserPrincipal() { 
     return new Principal() { 
      public String getName() { 
       return user.getName(); 
      } 
     }; 
    } 

    public String getAuthenticationScheme() { 
     return null; 
    } 
} 

Если вы предпочитаете использовать JaaS, вам придется настраивать безопасность в конфигурации вашего приложения. Вот некоторые примеры для встроенных Jetty.

+0

Сейчас у меня есть метод ресурсов с именем loginUser, который получает имя пользователя и пароль и проверьте, совпадает ли он с номером в db. Как я могу сказать, что этот механизм JerseySecurityContextFilter запускается при вызове этого класса ресурсов? –

+0

Когда пользователь входит в систему и выполняется ваш метод ресурса, создайте сеанс и поместите в него пользователя. Затем фильтр сможет проверить, существует ли пользователь в сеансе. Если да, то он вошел в систему, если не он. Вы можете добавить фильтр в майку, используя несколько методов. Один из них регистрирует класс фильтра с помощью ResourceConfig. –

+0

Теперь я понял, что немного ввел вас в заблуждение, предложив зарегистрировать пользователя в фильтре. Это было бы хорошо, если бы вы использовали что-то вроде Basic Auth. Если вы используете специальную форму или что-то подобное, поддерживаемое ресурсом с помощью метода входа, поместите объект пользователя в сеанс и просто вытащите его из сеанса в фильтре. Остальные могут оставаться прежними. Я могу обновить образец кода, если хотите. –

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