la seguridad camiseta y gestión de sesiones
https://stackoverflow.com/questions/909185
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
¿Hay una manera de conseguir la gestión de la seguridad de sesión o mediante programación en Jersey, por ejemplo, aplicación web de gestión de sesiones? O son transacciones, sesiones, y la seguridad de todo manejados por el contenedor en el que se despliega la aplicación Jersey?
Solución
Gestión de sesiones es de la competencia del recipiente en el que se despliega Jersey. En la mayoría de los casos de producción, se despliega dentro de un contenedor que lleva a cabo la gestión de sesiones.
El código siguiente es un ejemplo sencillo de un recurso camiseta que obtiene los valores objeto de sesión y almacena en la sesión y los recupera en llamadas posteriores.
@Path("/helloworld")
public class HelloWorld {
@GET
@Produces("text/plain")
public String hello(@Context HttpServletRequest req) {
HttpSession session= req.getSession(true);
Object foo = session.getAttribute("foo");
if (foo!=null) {
System.out.println(foo.toString());
} else {
foo = "bar";
session.setAttribute("foo", "bar");
}
return foo.toString();
}
}
Otros consejos
pensé que las sesiones es algo que debemos no en el uso aplicaciones RESTful ...
Yegor es correcto. No debemos nunca se mantenga el estado en el lado del servidor a La aplicación web convencional. Si usted quiere construir una desacoplado aplicación orientada a SOA no es necesario utilizar ningún API / marco para servicios web REST. Si necesita o desea, para mantener el estado de cliente-servidor global en el lado del servidor que está construyendo implícitamente lo que podríamos describir como una aplicación orientada a SOA-[web], pero usando Jersey como un [web] marco de desarrollo de las clases. Sin darse cuenta que está torciendo la naturaleza de un servicio web REST (o no). puede hacerlo de la manera que ha sido sugerido en la primera respuesta, pero no debe . El resultado final no es un servicio web, sólo una aplicación regular de construcción con herramientas de servicios web.
-_ o
Sí, es posible. Jersey documentación dice:
La información de seguridad de una solicitud está disponible mediante la inyección de un JAX-RS ejemplo SecurityContext usando @Context anotación. El inyectado ejemplo contexto de seguridad proporciona el equivalente de la funcionalidad API disponibles en HttpServletRequest. El contexto de seguridad inyectado depende de la implementación real de aplicaciones Jersey. Por ejemplo, para una aplicación Jersey desplegado en un contenedor Servlet, la Jersey SecurityContext encapsula la información de un contexto de seguridad recuperado de la petición de servlet. En caso de una aplicación de Jersey desplegado en el servidor del grisáceo, el SecurityContext volverá información recuperada de la solicitud del grisáceo.
Ejemplo:
@Path("basket")
public ShoppingBasketResource get(@Context SecurityContext sc) {
if (sc.isUserInRole("PreferredCustomer") {
return new PreferredCustomerShoppingBasketResource();
} else {
return new ShoppingBasketResource();
}
}
o
@Path("resource")
@Singleton
public static class MyResource {
// Jersey will inject proxy of Security Context
@Context
SecurityContext securityContext;
@GET
public String getUserPrincipal() {
return securityContext.getUserPrincipal().getName();
}
}
O si quieres seguridad fuera de la caja con anotaciones comprobar estos documentos .
Jersey también le permite personalizar la SecurityContext:
El SecurityContext puede ser recuperada directamente de ContainerRequestContext vía método getSecurityContext (). Tú también puedes reemplazar las SecurityContext por defecto en un contexto de la petición con una costumbre uno utilizando el método setSecurityContext (SecurityContext). Si se establece una variación propia SecurityContext en su ContainerRequestFilter, este instancia de contexto de seguridad será utilizado para la inyección en JAX-RS campos de clase de recursos. De esta manera se puede implementar una costumbre filtro de autenticación que puede configurar su propio SecurityContext sea usado. Para garantizar la pronta ejecución de su autenticación personalizada filtro de solicitud, establecer la prioridad de filtro para la autenticación utilizando constantes de prioridades. Una ejecución temprana de que la autenticación filtro se asegurará de que todos los filtros otros, recursos, métodos de recursos y localizadores de recursos sub-ejecutarán con su aduana ejemplo SecurityContext.
sobre el uso de filtros de petición con Jersey. Y comprobar mi siguiente ejemplo:
import javax.annotation.Priority;
import javax.ws.rs.Priorities;
@Provider
@Priority(Priorities.AUTHENTICATION)
public class AuthRequestFilter implements ContainerRequestFilter {
@Context
HttpServletRequest webRequest;
@Override
public void filter(ContainerRequestContext requestContext) throws IOException {
final HttpSession session = webRequest.getSession();
requestContext.setSecurityContext(new SecurityContext() {
@Override
public Principal getUserPrincipal() {
return new PrincipalImpl((String)session.getAttribute("USER_NAME"));
}
@Override
public boolean isUserInRole(String s) {
return false;
}
@Override
public boolean isSecure() {
return false;
}
@Override
public String getAuthenticationScheme() {
return null;
}
});
}
}
¡Atención! Esto se introdujo en Jersey 2.4 . 4.0.0 glassfish utiliza vieja Jersey 2.0, por lo tanto, tendrá que actualización Jersey uso de estos consejos (que no está demostrado para trabajar bien). O la mejor forma de hacerlo es descargar la acumulación nocturna de Glassfish 4.0.1 . pero no es completamente estable en este momento. Espero que la nueva versión se dará a conocer pronto.
ACTUALIZACIÓN: Por el momento (14/02/2014) Glassfish 4.0.1 nightly build utiliza Jersey 2.5.1 e inyección contexto funciona muy bien.
La respuesta de Jack acerca de las sesiones es correcta. Son específicos para el contenedor que se ejecuta en, aunque la especificación Servlet al menos le da la portabilidad entre contenedores JavaEE.
En cuanto a la seguridad, por lo menos tener la oportunidad de separarlo de sus JAX-RS código específico mediante el empleo de JAAS (JAAS) y un filtro de servlet . El filtro se puede utilizar para aplicar la autenticación HTTP y, en la autenticación exitosa, la configuración del sujeto JAAS con los directores correspondientes. Sus recursos JAX-RS puede comprobar si los directores apropiados sobre el tema. Dado que permite controlar toda la pila, debe ser capaz de confiar en un usuario autenticado en sus recursos (pero probar esto!), Y se puede hacer cumplir la autorización basada en la operación actual en el código de recursos.
He resuelto este problema haciendo que los clientes añadir la cabecera de Autorización y probarlo en el méthode RESTO como esto:
@GET
@PRODUCES(MediaType.APPLICATION_JSON)
public String returnClients(@Context HTTPServletRequest request(
String auth = request.getHeader("Authorization");
Account acc = null;
if (auth!=null) {
Account acc = Utils.LoginAccount(auth);
}
if (acc == null)
// not logged in, handle it gracefully
De esta manera no es la autenticación sin iniciar una sesión.
Para la seguridad de Jersey que debería echar un vistazo en el apoyo OAuth Jersey. OAuth encaja a la perfección cuando se exponen la API para su sistema para los usuarios externos. Por ejemplo como el api linkedin
Puede @path usuario para agrupar los servicios bajo el nombre único espacio. ejemplo.
@Path("/helloworld")
public class HelloWorld {
@GET
@Produces("text/plain")
public String hello() {
return "";
}
}Instead of @Path("/helloworld") use
@Path("admin/helloworld") to expose you class as rest and bind filter on "admin/"
in web.xml as below.
<servlet>
<servlet-name>jersey-serlvet</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>/</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>jersey-serlvet</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
<filter>
<filter-name>myfilter</filter-name>
<filter-class>com.Filterclass</filter-class>
</filter>
<filter-mapping>
<filter-name>myfilter</filter-name>
<url-pattern>/rest/admin/*</url-pattern>
</filter-mapping>
public class Filterclass implements Filter {
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
throws IOException, ServletException {
try{
chain.doFilter(request, response);
}catch(Exception e){
e.printStackTrace();
}
}
}Se puede validar la sesión en esta clase de filtro.
