작성
·
590
0
++추가적으로 찾아보다가 이제 조금 이해가 된 것 같습니다
제 생각대로 매 요청 시마다 쓰레드가 바뀌는 것이 맞고, 그렇기 때문에 SecurityContextHolder를 clear해주는 것이며 요청 시마다 세션을 이용해서 요청을 인가받는 게 맞는 것이죠?
SecurityContext를 매번 요청 시마다 불러와야야하는 건 요청에 대한 인가 정보를 불러오기 위함이고, 세션이라는 건 Security Context를 불러올 수 있는 키값으로 브라우저 종료, 혹은 일정 시간마다 만료되기 때문에 다시 로그인을 해줘야하는 것이구요.
조금 멍청한 질문이였던 것 같은데 그래도 아직 확신을 못해서 확인받고자 질문을 그대로 두었습니다! 확인만 한 번 해주시면 감사하겠습니다!
-안녕하세요 선생님 유익한 강의 너무 잘 듣고 있습니다.
오늘 제가 처음으로 Thread Local에 대해 배우고, 공식 문서도 찾아봤지만 제가 기존에 배운 지식과는 상충되는 부분이 있어 도저히 잘 이해가 되지 않아 질문 올리게 되었습니다.
다만 이 부분은 스프링 시큐리티 질문이 아니라 스프링 기초와 관계된 부분이라, 답변을 주지 않으셔도 할 말은 없습니다 ㅜㅜ 관련 검색어 혹은 링크라도 알려주실 수 있다면 정말 감사할 것 같습니다.
제가 기존에 알기로 HTTP 연결은 매 요청, 응답 단위마다(Three Hand Shake)혹은 Keep-Alive 지속 시간 동안 연결되는 것이고 또한 WAS에서 제공하는 Dispatcher Servlet은 미리 쓰레드풀에 쓰레드를 생성해놨다가 이 요청 단위마다 쓰레드를 주고 반환하는 것을 반복하는 것으로 알고 있었습니다. 그리고 또한 쓰레드로 인해 정보가 원치 않게 공유되는 것을 막기 위해 매번 쓰레드 반환 시 해당 쓰레드를 클리어하는 것으로 알고 있습니다.
그런데 어떻게 한 유저가 접속해서 브라우저를 종료하거나 혹은 만료 시간이 될 때까지 같은 쓰레드의 로컬 스토리지에 있는 정보를 이용할 수 있는 것인지가 너무 혼란스럽습니다.. ㅜㅜ;
아니면 계속해서 세션을 반복적으로 불러오는 것인가요?
제가 디버깅 경험이 부족하여 직접 확인하고 싶어도 어디를 건드려야할지 몰라 실천해보지는 못했습니다. ㅜㅜ
답변 1
1
아 네.
스스로 질문에 대한 답을 찾은 것 같습니다.
스레드는 매 요청마다 서버의 풀에서 할당하는 것이고 그래서 라이프 사이클 범위가 요청과 응답까지이며 세션은 쿠키가 만료되는 시점 혹은 브라우저가 종료되는 시점입니다.
SecurityContext 는 매 요청마다 새롭게 생성되거나 이미 생성되어 있다면 세션에서 가져오게 됩니다.
사실 스프링 시큐리티가 세션만 사용해서 인증처리를 하지 않고 ThreadLocal 을 사용하는 여러가지 이유가 있겠지만 그 중의 하나가 요즘은 인증처리 시 세션을 전혀 사용하지 않고 토큰 기반으로 인증을 처리하기 때문이기도 합니다
아하.. 어쩐지 그냥 세션에서만 바로 빼오면 되는데 쓰레드 로컬이 왜 필요한가 했더니 그런 이유였군요! 감사합니다!!