Подтвердить что ты не робот

Получение значений фактических параметров в ресурсе JerseyFilterFactory

Я хочу реализовать пользовательскую авторизацию в моих службах REST с помощью Jersey. Эта настраиваемая авторизация проверяет аннотации на методы, а также фактические параметры, которые метод получает.

Мой аннотированный метод jax-rs выглядит так:

@GET
@Path("customers")
@Requires(Role.CustomerManager)
public Customer getCustomer(@ParseFromQueryString @CheckPermission final Customer customer) {
    // ...
}

@ParseFromQueryString представляет собой аннотацию, которая указывает Джерси (через поставщика инъекций) на отмену a Customer из строки запроса. Код для этого выглядит так:

public class QueryStringCustomerInjectable implements Injectable<Customer> {
  public Customer getValue() {
    final Customer customer = new Customer();
    // ... a UriInfo was injected using the @Context annotation
    // ... extract parameters from QueryString and use setters
    return customer;
  }
}

Аннотация @CheckPermission указывает мой пользовательский авторизатор, что разрешения должны быть проверены на клиенте. Некоторые пользователи имеют доступ к информации о некоторых клиентах. Аналогично, аннотация @Requires принимает роль, которую должен иметь invoker. Это не роли Java-роли (строки), скорее, они являются значениями перечисления.

Используя Jersey ResourceDebuggingFilter в качестве отправной точки, я смог досконально узнать, какой метод будет вызываться. Тем не менее, я до сих пор не понял, как определить, какие параметры будут фактически использоваться для вызова метода.

В верхней части моей головы я могу думать о двух работах:

  • Перехватчик метода с использованием Guice + Jersey.
  • Обозначьте эту логику в QueryStringCustomerInjectable, но это кажется немного неряшливым. Это будет класс, делающий слишком много.

Тем не менее, я бы очень хотел сделать это, используя только Jersey/JAX-RS. Я чувствую, что я так близко!

Идеи? Указатели?

Спасибо!

4b9b3361

Ответ 2

Для десериализации клиента вы можете реализовать javax.ws.rs.ext.ParamConverterProvider и зарегистрировать его на Джерси. Затем вы можете ввести его в свои методы с помощью @QueryParam ( "клиент" ). Это немного более гибко, поскольку вы можете использовать его также с аннотациями @BeanParam или @PathParam.

Затем вы можете использовать ContainerRequestFilter. См. В качестве ссылки, как Джерси делает Oauth1, например OAuth1ServerFilter. Следующее, что вы можете сделать, это создать, возможно, функцию, которая будет регистрировать вновь созданный фильтр (см. Oauth1ServerFeature для справки - я не мог" t найти исходный код прямо сейчас).

Удачи!

Ответ 3

Почему бы вам не использовать собственный фильтр сервлета, например

public class YourFilter implements Filter {
  ...
  @Override
 public void doFilter(ServletRequest request, ServletResponse response,
        FilterChain filterChain) throws IOException, ServletException {

    // HttpServletRequest httpReq = (HttpServletRequest) request;
    // HttpServletResponse httpResp = (HttpServletResponse) response;

    // HttpServletRequest httpReq = (HttpServletRequest) request;
    // HttpServletResponse httpResp = (HttpServletResponse) response;
    // ..... httpReq.getUserPrincipal();


    // then set what you need using ThreadLocal and use it inside your resource class

    // do not forget to call 
    filterChain.doFilter(request, response); // at the end of this method

 }

Последний шаг - зарегистрировать ваш фильтр сервлета. Это делается с помощью веб-приложения web.xml

Он перехватит ваши HTTP-запросы до того, как будет вызываться реальный код внутри ресурса jersey.