cas client 클 라 이언 트 클 라 이언 트 클 라 이언 트 클 라 이언 트 클 라 이언 트 클 라 이언 트 클 라 이언 트 클 라 이언 트 클 라 이언 트 클 라 이언 트 클 라 이언 트 클 라 이언 트 클 라 이언 트 클 라 이언 트

cas client 는 단일 점 출 기능 SLO 를 제공 합 니 다. 그러나 cas client 가 클 러 스 터 환경 에서 단일 점 에 올 라 가 는 상황 에 대해 깊이 이해 하 는 것 은 매우 적 습 니 다. 기본 적 인 상황 에서 잘 알 지 못 하기 때 문 입 니 다. 즉, 때로는 올 라 갈 수 있 고, 때로는 올 라 갈 수 없 는 상황 이기 때 문 입 니 다.최근 한 동안 새로운 회사 에서 기술 예행연습 을 하 다가 이 문제 에 또 부 딪 혔 기 때문에 이에 대해 깊이 알 아 보 자.
배치 설명
프로젝트A. 두 개의 tomcat 1 을 배치 하고 tomcat 2 포트 는 각각 8080, 9090 이 며 nginx 운영 부 구 는 80 이 고 ip 는 192.168.3.1100. ca server 로 통일 되 어 단기 192.168.3.10.1: 8080 이다.

cas - client. jar 버 전 번 호 는 3.4.1 (github 에서 cas client 는 여러 해 동안 업데이트 되 지 않 았 다).

cas server 버 전 번호 4.1.10, 참조 가능https://github.com/zhuzhong/cas-web.git

nginx 역방향 에이전트 tomcat 1, tomcat 2, 순조롭게 로그 인 할 수 있 도록 다음 세 가지 옵션 이 필요 합 니 다.

nginx 경로 규칙 iphash

nginx session sticky

tomcat session 클 러 스 터 또는 session 공유;

여기 서 나 는 iphash, 최종 nginx 의 upstream 부분:

    upstream pro_a {
            ip_hash;
            server 192.168.31.101:8080;
            server 192.168.31.101:9090;
        }

질문
사용 자 는 브 라 우 저 를 통 해 192.168.3.100 / proj 를 방문 합 니 다.a / index 를 방문 하면 로그 인 에 성공 할 수 있 습 니 다.하지만 한 지점 에 문제 가 생 겨 게재 가 불가능 할 때 도 있다.
단일 지점 게재 문제 원인 분석
cas client 는 사용자 가 로그 인 할 때 HashMapBacked Session MappingStorage (jvm 에서) 에 token 과 현재 httpSession 의 대응 관 계 를 저장 합 니 다.사용자 가 proj 에 접근 할 때A 통과 iphash 경로 가 tomcat 1 로 가면 httpsession 은 tomcat 1 에서 만 들 고 tomcat 1 의 jvm 에 저 장 됩 니 다.
사용자 가 로그 인 요청 을 보 낼 때, cas server 는 기본적으로 BACK 을 사용 합 니 다.CHANNEL 메시지 알림 로그아웃 요청 (logoutrequest), nginx iphash 경로 이후 tomcat 2 까지 갈 수 있 습 니 다. 그리고 token 을 통 해 해당 httpsession 을 가 져 올 수 없 기 때문에 한 번 에 로그 인 할 수 없습니다.
솔 루 션 1 버 전
카 스 클 라 이언 트 의 단일 지점 종료 코드 를 수정 합 니 다. 2 차 그룹 방송 을 진행 하여 게재 요청 을 보 냅 니 다.구체 적 인 설명 은 다음 과 같다.hash 에서 tomcat 2 까지 이러한 상황 은 2 차 처리 합 니 다.즉, 해당 httpsession 을 찾 지 못 했 을 때 proja 의 모든 배치 노드 에 대해 2 차 로그 인 요청 을 합 니 다. 여기 서 바로http://192.168.31.100:8080/proj_a/index,http://192.168.31.100:9090/proj_a / index 에서 로그아웃 요청 을 보 냅 니 다.노드 tomcat 1 에서 해당 하 는 httpsession 을 찾 아 무효 로 하면 작업 을 수행 합 니 다.
그러나 여기 에는 전단 로그 인 페이지 가 두 번 다시 로그 인 페이지 로 돌아 갈 수 없다 는 문제 가 남아 있 습 니 다. 로그 인 요청 을 보 내 는 페이지 에 머 물 러 사용자 에 게 가상 으로 로그 인 하지 않 았 습 니 다.그 러 니까 이 건 완벽 한 해결책 이 아니 야.이 버 전에 대한 수정 코드 참조https://github.com/zhuzhong/cas-client-logout-extend.git 분기 명 logout - broadcast.
솔 루 션 2 버 전
nginx 의 iphash, tomcat session cluster 로 바 꾸 어 좋 은 결 과 를 얻 으 려 고 하지만 문 제 는 여전히 완벽 한 해결 방안 이 아니다.만 들 기 전에 결론 은 솔 루 션 1 버 전 결과 와 같다.해 보 는 이 유 는 기술자 들 이 그 렇 기 때문에 모든 일 을 해 봐 야 알 수 있다.
솔 루 션 제3 버 전
이 방안 은 우연히 발견 한 것 이다.카 스 클 라 이언 트 의 단일 로그 인 코드 수정 을 진행 할 때 SingleSignOutHandler. is FrontChannel LogoutRequest 는 호출 되 지 않 고 SingleSignOutHandle. is BackChannel LogoutRequest 만 호출 되 는 방법 이 있 습 니 다.애초에 도 신경 쓰 지 않 았 다. 게재 논리 가 이 렇 기 때문에 다른 방식 을 사 용 했 을 뿐이다.그러나 SingleSignOutHandler. process 방법 에 서 는 isFrontChannel LogoutRequest 에 대해 한 번 더 방향 을 바 꾸 었 습 니 다.그래서 과감하게 게재 방식 을 FRONT 로 바 꿨 습 니 다.CHANNEL, 그리고 테스트, ok, 문제 없 이 미리 설 정 된 목적 을 달성 할 수 있 습 니 다.로그아웃 방식 의 변경 사항 은 cas server 에서 src / main / resources / services / HTTPSandIMAPS - 1000000001. json 의 "logoutType": "BACK CHANNEL", "logoutType": "FRONT CHANNEL" 로 변경 하면 됩 니 다.
총결산
몇 가지 버 전 을 거 쳐 며칠 동안 의 고통 과 괴로움 을 겪 은 이 문 제 는 마침내 결 과 를 얻 은 셈 이다.이 문 제 를 빨리 해결 하지 못 한 이 유 는 카 스 의 등장 논리 에 익숙 하지 않 기 때문이다.그동안 로그 인 에 만 관심 을 갖 고 등 판 에 별 관심 을 갖 지 않 았 다.로그 인 에 대해 프로그래머 들 은 브 라 우 저 를 끄 는 묘수 가 있다.그래서 이것 에 대해 깊이 연구 하지 않 아 이해 가 깊 지 않다.나중에 시간 이 있 으 면 카 스 의 등장 에 대해 상세 한 분석 을 한다.