2011-06-20 10 views

Respuesta

102

Depende de cómo lo haya configurado (o, por ejemplo, puede configurar un comportamiento diferente).

En una aplicación web usará ThreadLocalSecurityContextHolderStrategy que interactúa con SecurityContextPersistenceFilter.

El Java Doc de SecurityContextPersistenceFilter comienza con:

rellena la {@ link} SecurityContextHolder con información obtenida del configurado {@ link SecurityContextRepository} antes de la la solicitud y lo almacena en la espalda el repositorio una vez completada la solicitud y borrar el contexto titular. De forma predeterminada, usa un {@link HttpSessionSecurityContextRepository}. Consulte esta clase para obtener información HttpSession relacionada con opciones de configuración.

BTW: HttpSessionSecurityContextRepository es la única aplicación de SecurityContextRepository (He encontrado en las librerías por defecto)

Funciona así:

  • El HttpSessionSecurityContextRepository utiliza el HttpSession (= clave" SPRING_SECURITY_CONTEXT ") para almacenar un objeto SecurityContext.
  • El SecurityContextPersistenceFilter es un filtro que usa un SecurityContextRepository por ejemplo HttpSessionSecurityContextRepository para cargar y almacenar objetos SecurityContext. Si un HttpRequest pasa el filtro, el filtro de conseguir la SecurityContext desde el repositorio y lo puso en la SecurityContextHolder (SecurityContextHolder#setContext)
  • El SecurityContextHolder tiene dos métodos setContext y getContext. Ambos usan un SecurityContextHolderStrategy para especificar qué se hace exactamente en los métodos set y get-Context. - Por ejemplo, el ThreadLocalSecurityContextHolderStrategy usa un hilo local para almacenar el contexto.

En resumen: El usuario principal (elemento de SecurityContext) se almacena en la sesión HTTP. Y para cada solicitud, se coloca en un hilo local desde donde se accede.

Cuestiones relacionadas