SecurityContextHolder는 안전합니까?

나는 SecurityContextHolder 사용하고 사용자 정의 UserDetailsService는 SecurityContextHolder에서 UserDetails를 얻을 :SecurityContextHolder는 안전합니까?

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

가 나는 등 널 검사를, 왼쪽으로, 그러나 그것은 생각입니다. SecurityContextHolder 클래스를 보면

이

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

, 그것은 기본적으로 ThreadLocal를 사용하지만 포인트 컷 물건은 캡슐화 스레딩 논리의 일종을 갖고있는 것 같아요 : 나는 @Aspect의 @Around 포인트 컷이 사용하고 있습니다.

사용자 충돌 (다른 동시 세션의 UserB 감사 이벤트에 대해 하나의 세션에서 UserA에 액세스) 또는 null 사용자가있을 수 있습니다.

자격 증명/사용자 프로필을 얻는 더 좋은 방법이 있습니까?

출처

2010-02-18 Droo

네, 기본 전략 (MODE_THREADLOCAL)으로 스레드 안전성입니다 (즉석에서 전략을 변경하지 않는 한). 그러나 스폰 된 스레드가 상위 스레드의 SecurityContext을 상속하도록하려면 MODE_INHERITABLETHREADLOCAL을 설정해야합니다.

또한 측면에는 "스레딩 논리"가 없으므로 adviced 메서드와 동일한 스레드에서 실행됩니다.

출처

2010-02-18 20:49:48 axtavt

나는 그것을 보았다. 그러나 사람은 그것이 봄 녀석들에게는 커다란 난점과 같다. 정적 인 util 클래스와 setStrategyName에는 다음과 같은 Javadoc blurb가 있습니다.'주어진 JVM에 대해이 메소드를 두 번 이상 호출하지 마십시오. 전략을 다시 초기화하고 기존 전략을 사용하여 기존 스레드에 나쁜 영향을 미치므로. 결국 싱글 톤 래퍼 클래스가 생성됩니다. – Droo

나는 또한 시스템 속성이 있다고 생각한다.'public static final String SYSTEM_PROPERTY = "spring.security.strategy";' – Droo

-1

예 스레드로부터 안전합니다. 일반적으로 SecurityContextHolder.getContext(). getAuthentication(). getName()

출처

2012-02-28 20:15:34 vsingh

downvote에 대한 이유는 제발 – vsingh

일반적으로 ThreadLocal은 전역 캐시 된 스레드 풀에서 친숙하지 않습니다. ExecutorService의 기본 캐시 된 스레드 풀 (Executors.newCachedThreadPool())은 초기화 스레드의 ThreadLocal 저장소 또는 비어있는 스레드 풀 중 하나를가집니다. 이 상황에서 MODE_INHERITABLETHREADLOCAL을 설정하면 캐싱 된 스레드 풀이 요청 당 초기화되지 않는 한 아무 것도 변경되지 않습니다. 이는 매우 나쁜 사용법입니다. 기본 프레임 워크 또는 라이브러리가 Executors.newCachedThreadPool()을 사용하여 스레드 풀링.

출처

2013-02-05 17:31:13 bmadigan

SecurityContextHolder는 안전합니까?

답변

관련 문제