Le thread SecurityContextHolder est-il sécurisé?

J'utilise SecurityContextHolder et une coutume UserDetailsService pour obtenir UserDetails de SecurityContextHolder:Le thread SecurityContextHolder est-il sécurisé?

Object o = SecurityContextHolder.getContext().getAuthentication().getPrincipal(); 
UserDetailsDTO user = (UserDetailsDTO) o;

je quittais les chèques nuls, etc., mais c'est l'idée. J'utilise ceci dans un @Around pointcut d'un @Aspect:

@Around("execution(* user.service.*.*(..))") 
public Object audit(ProceedingJoinPoint call) throws Throwable { 
    // get user id 
    // add audit row in db 
}

regardant la classe SecurityContextHolder, il utilise un ThreadLocal par défaut, mais les choses pointcut semble aussi avoir une sorte de logique de filetage encapsulé.

Est-il possible qu'il puisse y avoir une collision de l'utilisateur (c'est-à-dire accéder à UserA à partir d'une session pour un événement d'audit UserB dans une autre session simultanée), ou éventuellement un utilisateur nul.

Existe-t-il un meilleur moyen d'obtenir les informations d'identification/profil utilisateur?

Source

2010-02-18 Droo

Oui, il est thread-sûr avec la stratégie par défaut (MODE_THREADLOCAL) (tant que vous n'essayez pas de changer la stratégie à la volée). Toutefois, si vous souhaitez que les threads créés génèrent SecurityContext du thread parent, vous devez définir MODE_INHERITABLETHREADLOCAL.

Les aspects n'ont pas non plus de "logique de threading", ils sont exécutés au même thread que la méthode conseillée.

Source

2010-02-18 20:49:48 axtavt

Je l'ai vu, mais l'homme semble-t-il comme une énorme erreur pour les gars du printemps. Une classe util statique, et setStrategyName a ce texte Javadoc: 'NE PAS appeler cette méthode plus d'une fois pour une JVM donnée, car elle réinitialisera la stratégie et affectera négativement les threads existants en utilisant l'ancienne stratégie.» Je pense que je vais probablement finir par créer une classe wrapper singleton. – Droo

Je suppose qu'il existe également une propriété système: 'static public final String SYSTEM_PROPERTY =" spring.security.strategy ";' – Droo

-1

Oui, il est thread-safe. Vous devriez simplement appeler SecurityContextHolder.getContext(). GetAuthentication(). GetName()

Source

2012-02-28 20:15:34 vsingh

Raisons pour downvote s'il vous plaît – vsingh

En général, ThreadLocal ne sera pas convivial dans un pool de threads global mis en cache. Le pool de threads mis en cache par défaut d'ExecutorService (Executors.newCachedThreadPool()) aura le stockage ThreadLocal du thread d'initialisation, ou un espace vide. Dans ce cas, la définition de MODE_INHERITABLETHREADLOCAL ne changera rien, à moins que le pool de threads mis en cache ne soit initialisé par requête, ce qui serait une mauvaise utilisation. Assurez-vous que les frameworks ou bibliothèques sous-jacents n'utilisent pas Executors.newCachedThreadPool() pour fournir thread pooling pour vous.

Source

2013-02-05 17:31:13 bmadigan

Le thread SecurityContextHolder est-il sécurisé?

Répondre

Questions connexes