2021-01-12 sp6
쿠키를 지우겠다고 했는데 왜 안지워지냐
CookkieClearLogoutHandler
setMaxAge(0)이면 주의? 이름과 맥스 에이지 말고는 동일한 경우에만 사용이 가능하다.
주석에 보니 쿠키의 패스가 context path인 경우에만 지울수 있다.
변경후 탈퇴 한 회원은 로그인이 안되어야한다.
하지만 되고 있었다.
지금까지는 빈을 직접 등록한적이 없지만
시큐리티의 이것은 빈을 등록하고 있던 것이다
<authentication-manager id="authenticationManager">
<authentication-provider user-service-ref="customUserService">
<password-encoder ref="passwordEncoder" />
</authentication-provider>
</authentication-manager>
직접 이것을 이용하여 바꿀 수 있다?
<beans:bean id="authenticationProvider" class="org.springframework.security.authentication.dao.DaoAuthenticationProvider"
p:userDetailsService-ref="customUserService"
p:passwordEncoder-ref="passwordEncoder"
p:hideUserNotFoundExceptions="false"
/>
<authentication-manager id="authenticationManager">
<authentication-provider ref="authenticationProvider" />
</authentication-manager>
이렇게 변경하면 우리꺼 쓸 수 있다.
오류 메시지가 로케일 설정에 따라 들어가야한다.
여기있는 녀석을 가져다가 쓸 수 있어야한다. 지금은 무조건 맨 아래의 message만 사용되는 것
servlet-context.xml 의 로케일 리졸버를 변경
상위에 시큐리티가 있는데
하위에 메시지 소스가 존재한다. 따라서 안된다.
그래서 상위인 시큐리티로 옮김.
했다니 하위 컨테이너에서는 로케일 처리가 되는데 상위에서는 안된다.
회원조회는 영한글 잘나오는데 로그인에는 영/한 교환 처리가 안됨.
참고 : spring.io
Spring Security relies on Spring’s localization support in order to actually lookup the appropriate message. In order for this to work, you have to make sure that the locale from the incoming request is stored in Spring’s org.springframework.context.i18n.LocaleContextHolder. Spring MVC’s DispatcherServlet does this for your application automatically, but since Spring Security’s filters are invoked before this, the LocaleContextHolder needs to be set up to contain the correct Locale before the filters are called. You can either do this in a filter yourself (which must come before the Spring Security filters in web.xml) or you can use Spring’s RequestContextFilter. Please refer to the Spring Framework documentation for further details on using localization with Spring.
org.springframework.context.i18n.LocaleContextHolder 안에 로케일 안에서 처리해하는데 이것이 디스패처 서블릿 에서 처리해야하는데 우리가 사용하는 것은 디스패처 서블릿보다 앞에 온다.
(시큐리티를 탄 이후에 하는 것, 인터셉터가 동작하지 않는 것)
로케일 처리를 위한 필터를 만들어서 너가 web.xml넣거나 RequestContextFilter 를 이용?
허나 우리는 스프링 안에서 동작할 수 있는 필터가 필요하다. 컨테이너 내부 필터
어떻게 만들 것인가? web.xml 등록하던지 스프링의 RequestContextFilter 를 이용하라 했으니 RequestContextFilter 이용?
스프링의 리멤버미?
아이디 기억하기 - 이벤트 헨들러로 처리
배치를 쓰는대신에? 여타의 다른 것을 해볼??
배치는 대용량의 일괄데이터를 처리할때 사용한다. (대용량에 관한 내용이 없어?)
그래서 스케줄링
웹소켓 실시간 양방향 통신
오후 배치의 핵심 스레드, 스케줄, 스케줄러 프레임워크
long polling, SSE 등 ...
WebSocket protocol?(http 하위) 브라우저가 결정한다. 자동구조
커넥션의 라이프 사이클을 직접 제어할 수 있다. 통로를 개방하고 계속 유지할 수도 있다.
유지되는 상황에서는 실시간으로 양방향통신이 가능하다. 이것이 웹 소켓
단점 : 모든 클라이언트에 대해서 부하는 감당해야한다.
웹소켓은 한번 통로를 개설하고나면 헤더 정보가 포함이 안된다. 콕집어서 데이터만
그래서 오고 가는 데이터가 크지 않다.
그래서 이 최소한의 통로에서 웹소켓을 이용. 이 통로를 어떻게 개설하지 ㅇ알아야한다.
데이터가 왔다라면 받는 방법, 보내는 방법, 연결을 끊는 방법, 자바 스크립트가 지원하는 웹 소켓?
검색어 : websocket echo site
참고 : https://www.websocket.org/echo.html
100번대를 쓰는 녀석 웹소켓 101 프로토콜 전환중이다?
자바스크립트 의 웹소켓 API http/1.1 버전 부터 지원
그 이전에는 SockJS
이벤트 드리븐 방식
- 플로우 처리, 핸들러를 이용해서 플로우처리
어떤 상황이 발생했을 그 상황에 따른 핸들러를 만들어 처리하는 것을 의미
테스트 드리븐
- 어플리케이션 구성할때 로직이 아니라 테스트 케이스부터 만들고 테스트케이스를 만들고 그 다음에 케이스를 만족하는 로직을 구현
우리 서버 안에 있어야한다? -
pdf ~p.8 , 웹소켓의 기본개념 자바에서의
p.9~ , 서버 사이드를 구현, 그냥 웹 소켓 API(저수준 API까지 수준이 높다), 자바스크립트API+ 자바API, 스프링 3버전으로 구현
p.14 ~ 18, 스프링을 이용한 서버사이드 프로그래밍
p.19 ~ 클라이언트 사이드 프로그래밍
p.22 SockJS를 이용한 클라이언트 사이드
pom.xml 에 dependency 추가
텍스트, 바이너리 웹소켓 핸들러 각각 이진과 문자 데이터 다른 방식으로 처리
서버에서도 4가지 상황에 대한 이벤트 처리가 필요
onopen - afterConnectionEstablished
onmessage - handleTextMessage
onerror - handleTransportError
onclose - afterConnectionClosed
채팅 기능 구현하려면 웹소켓 세션과 HTTP 세션 연동해야한다.
p.18 HttpSession 과 WebSocketSession 간의 데이터 공유(Handshaking 커스터마이징)
만들어지는 시점에 세션을 담으면 계속 있지 않겠느냐
핸드 쉐이크 인터 셉터 handShakeInterceptor
http Session의 정보를 옮겨 담아 웹소켓 세션에 담아야한다. 어센틱 정보까지
이벤트 발생 (이벤트 발행 - 주체가 필요 applicationEventPublisher)
스프링 스케줄링 이것을 이용해서 어떻게 배치를 처리하는지?
배치를 위한 스레드 기본 기술을 익히고 내일 ~
어떤 명령의 처리
실시간 처리
- 즉시 돌아오는 구조
배치 처리
- 즉시 돌아오지 않는 구조, 모아 두었다가 한꺼번에 처리하는 구조
배치 처리의 실행
-
백그라운드 실행
- 사용자의 인터렉션이 필요 없다 (사용자의 명령이 실시간이 아니다, 명령이 없어도 자동으로 실행)
- 멀티 스레드, 데몬 스레드
-
반드시 스케줄링 사용
- 특정 시간에 일정 주기에 따라 실행
- 스케줄러
-
스레드 job을 하기 위해 최소한의 자원을 할당 받는 객체
Timer 스케줄러, TimerTask
스레드를 버리지 말고 재활용할 수 있는 구조? ThreadPoolExecutor
풀링 + 풀링에 대상이 스레드 + 실행자? 작업을 실행해주는 역할자
백그라운드 실행
- 사용자의 인터렉션이 필요 없다 (사용자의 명령이 실시간이 아니다, 명령이 없어도 자동으로 실행)
- 멀티 스레드, 데몬 스레드
반드시 스케줄링 사용
- 특정 시간에 일정 주기에 따라 실행
- 스케줄러
스레드 job을 하기 위해 최소한의 자원을 할당 받는 객체
Timer 스케줄러, TimerTask
스레드를 버리지 말고 재활용할 수 있는 구조? ThreadPoolExecutor
풀링 + 풀링에 대상이 스레드 + 실행자? 작업을 실행해주는 역할자
필드에서는 프레임워크의 API를 이용하지만
내부적으로는 ThreadPoolExecutor 가 돌아간다. pooling
Author And Source
이 문제에 관하여(2021-01-12 sp6), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@hkjs96/2021-01-12-sp6저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)