java - Jersey y HK2-usuario actual de inyección

dependency-injection jersey-2.0

Question

Estoy trabajando con jersey 2.17 y HK2 para crear una aplicación de descanso simple. Tengo un ContainerRequestFilter que rechaza cualquier solicitud que no tenga la cookie "usuario actual".

Tengo algo como esto:

@Path("/users")
public class UserResource { 

      private UserService userService; 

      @GET
      @Path("/orders")
      @Produces("application/json")
      public List<Order> findOrdersOfCurrentUser() { 
            // some ugly code to access headers, extract cookies, and finally
            // extract username (a String) from a particular cookie

            return this.userService.findOrdersByUsername(username) ; 
      }
}

Quiero codificar algo más elegante que eso. Me gusta esto:

 @Path("/users")
 public class UserResource { 

          private UserService userService; 

          @CurrentUsername
          private String currentUser; 

          @GET
          @Path("/orders")
          @Produces("application/json")
          public List<Order> findOrdersOfCurrentUser() { 
                return this.userService.findOrdersByUsername(username) ; 
          }
    }

Soy muy nuevo en hk2 y me resulta muy difícil encontrar la manera de hacerlo.

Solo estoy pidiendo la interfaz correcta para implementar (o clase para ampliar).

Answer 1

Lo que estás buscando no se hace trivialmente. Una forma de manejar esto es establecer el SecurityContext dentro de ContainerRequestFilter , como se ve aquí . Esto no implica ninguna interacción directa con HK2. A continuación, puede inyectar SecurityContext en su clase de recursos. Y obtener el usuario por

securityContext.getUserPrincipal().getName();

Si realmente desea agregar el nombre de usuario con una anotación personalizada, deberá crear un InjectionResolver ( consulte Definición de la anotación de inyección personalizada . Puede inyectar ContainerRequestContext (el mismo que pasó al método de filtro en el ContainerRequestFilter ) o el SecurityContext en el InjectionResolver . Por ejemplo

Filtrar

@Provider
@PreMatching
public class UserFilter implements ContainerRequestFilter {

    public static final String USER_PROP = "user";

    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        requestContext.setProperty(USER_PROP, new User("peeskillet"));
    }
}

Anotación

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface CurrentUser {   
}

InjectionResolver

public class CurrentUserInjectionResolver implements InjectionResolver<CurrentUser> {

    javax.inject.Provider<ContainerRequestContext> requestContext;

    @Inject
    public CurrentUserInjectionResolver(
        javax.inject.Provider<ContainerRequestContext> requestContext) {
        this.requestContext = requestContext;
    }

    @Override
    public Object resolve(Injectee injectee, ServiceHandle<?> sh) {
        if (User.class == injectee.getRequiredType()) {
            return requestContext.get().getProperty(UserFilter.USER_PROP);
        }
        return null;
    }

    @Override
    public boolean isConstructorParameterIndicator() { return false; }

    @Override
    public boolean isMethodParameterIndicator() { return false; }
}

Enlace el InjectionResolver

@Provider
public class UserFeature implements Feature {

    @Override
    public boolean configure(FeatureContext context) {
        context.register(new AbstractBinder(){
            @Override
            public void configure() {

                bind(CurrentUserInjectionResolver.class)
                .to(new TypeLiteral<InjectionResolver<CurrentUser>>(){})
                        .in(Singleton.class);
            }
        });
        return true;          
    } 
}

Recurso

@Path("user")
public class UserResource {

    @CurrentUser 
    private User user;

    @GET
    public Response getCurrentUser() {
        return Response.ok(user.getUsername()).build();
    }
}

Ahora no estoy seguro de este segundo enfoque, al menos la parte sobre el filtro es un filtro @PreMatching . Si no hago una pre-coincidencia, el User será nulo. Parece que ContainerRequestContext aún no tiene la propiedad que establecimos, lo que significa que lo que parece estar sucediendo es que se llama a InjectResolver antes del filtro. Tendré que investigar esto. Haciéndolo una pre-coincidencia, IMO no debería ser requerido.

Personalmente, me gustaría ir con el primer enfoque, simplemente usando el SecurityContext . Un ejemplo completo está en el enlace que proporcioné arriba. Con este enfoque, puede aprovechar la RolesAllowedDynamicFeature de Jersey si es necesario.