Security를 이용한 로그인 처리

p.606~

 

새로운 요청이 들어올때 마다 서버측에서 쿠키에 세션ID가 있는지 검사를 한다

요청에 세션ID가 포함되어 있으면, 세션 공간과 맵핑하여 인지 후 프로그램이 진행된다

세션ID가 없거나, 틀리면 서버는 무조건 새로 생성해서 돌려주게 된다.

있더라도 서버공간을 찾아 일이시키지 못 하면 새로 돌려주게 된다.

 

스프링 시큐리티의 기본 동작 방식: 서블릿의 여러 종류의 필터와 인터셉터를 이용해서 처리 됨

• 필터 : 스프링과 무관하게 서블릿 자원
• 인터셉터 : 스프링의 빈으로 관리되면서 스프링의 컨텍스트 내에 속한다

    공통사항 : 특정한 서블릿이나 컨트롤러의 접근에 관여한다

 

 

 

 

Http는 보안에 취약함.

 

fileter를 이용한 처리 -> web.xml

 

 

 

 

 

 

5.0을 지워준다

 

filter-name이 같아야함

param-name 의 contextConfigLocation은 약속되어 있음 

 

 

 

메서트 타입이 void이므로 샘플 폴더 아래 all.jsp , member.jsp, admin.jsp가 있어야함

 

 

 

 

/sample/member를 입력하면 로그인페이지를 만든적도 없지만 login페이지가 뜸.

모듈에서 자동으로 지원해줌

 

 

서버측에서 세션 공간 삭제 되는 경우

 

1) 세션 타임아웃되면 세션 공간 삭제됨

2) 프로그래머가 강제적으로 삭제

 

세션 ID 는 쿠키에 저장됨. 브라우저 종료 전까지 쿠키는 살아있게 됨. 브라우저가 살아있으면 세션에 쿠키가 전달됨.

세션 ID가 없으면 새로 접속하는 것

 

클라이언트 서버 어떻게 동작하는지 알아야 한다.

 

 

 

세션ID삭제하면 로그아웃 됨

 

 

 

클라이언트 :  Request 요청 (세션ID없는상태) -> 서버 세션공간 만들고, 특정한 값을 넣고 Response할때 쿠키에 세션ID를 넣어 돌려준다 

 

세션 타임아웃되면 세션 공간이 날아감

세션ID가 새로만들어지면 로그인 유지 안 됨

 

 

 

sample/member에서 admin ID와 PW로 로그인 시 접속 불가

 

 

url을 강제로 요청시킨다 싶으면 Redirect가 떠올라야 함.

클라이언트가 url요청을 서버로 보내면 컨트롤러가 받고 accessError 핸들링이 있어야한다.

url이 있으면 컨트롤러가 있어야하고 RequestMapping이 처리되어야 한다

 

 

parameter로 넣을수 있는 것은 클라이언트 측에서 넘겨주는 데이터

뷰로 연결해서 사용하고 싶은 데이터

request, response 

 

 

scope :

page,

request(연결이 유지된 한 리퀘스트안에서) - model (  뷰로 넘길때)

session - 세션이 연결되어 있으면

application - 세션이 달라도 공유할 수 있는 레벨

 

model, HttpSession 두 가지로 가능

/sample/member에서 member로 로그인했을때, /sample/admin페이지를 들어갔을때 error페이지를 jsp로 보여줌

 

 

 

커스텀 로그인