스프링의 작동 원리 - 로그인편

 

로그인을 통한 스프링 작동 원리 설명

 

 

 

1. 톰캣이 켜져있을 때 사용자가 request 요청을 하면

 

2. request가 필터에서 필터링 해줄 것들이 필터가 되고

 

3. 디스패처한테 들어온다. 디스패처는 컨트롤러 하나를 메모리에 띄워야한다.

 

4. /login이 들어왔다면 /login이라는 주소가 있는 것을 컨트롤러를 메모리에 띄운다.

@PostMapping("/login")을 가지고 있는 메서드가 있는 컨트롤을 띄운다.

그 컨트롤러는 이제 username과 password를 받는다.

컨트롤러는 이렇게 username과 password를 받는 역할에서 끝난다.

컨트롤러의 역할은 어떤 주소 요청이 왔을 때 주소 요청에 대한 함수를 하나 만들어서

그 함수의 데이터(body data)를 받는 역할이다.

 

5. 이제 이 받은 데이터를 서비스에게 넘기게 된다.

그러면 서비스는 login 시작을 수행하게 된다.

그런데 login을 하기 위해서는 데이터베이스한테 질의를 해야한다. 로그인이니 select 질의를 해야한다. 

DB에 이 username과 password가 있는 사용자가 있나요? 하고 select 요청을 해야한다.

서비스는 이 select 요청을 JPA repository한테 위임하게 된다.

 

6. JPA repository는 이제 자신이 들고있는 함수를 호출한다.

select * from user where username = ? and password = ?

user테이블에 username과 password가 있는 사용자가 있는지 묻는 이런 쿼리 요청을 할 것이다. 

이렇게 요청을 하면 이 해당 요청에 대한 영속성 컨텍스트가 있는지 확인한다.

user테이블에 username과 password가 일치하는 어떤 애가 있는지 확인했으니

 

7. user라는 오브젝트가 영속성 컨텍스트에 존재하는지 물어보게 된다.

그런데 최초 요청을 하면 영속성 컨텍스트는 아무것도 없이 비어있다. (존재X)

 

8. 그러면 바로 Datasource한테 user오브젝트가 존재하는지 데이터베이스한테 직접 물어봐달라고 요청한다.

그러면 Datasource는 데이터베이스한테 질의요청을 하게 된다.

*Datasource는 DBCP를 구현하기 위한 인터페이스이다. Database Connection Pooling 기술이다.

 

9. 질의 요청을 해서 실제 select를 해봤는데 그 결과가 존재하면

데이터베이스한테서 user오브젝트를 리턴받는다.

 

10. 영속성 컨텍스트에 해당 user 오브젝트가 만들어지게 된다.

* 영속성 컨텍스트란 엔티티를 영구 저장하는 환경이다.
애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 한다.

 

11. 이렇게 영속성 컨텍스트에 user 오브젝트가 생성되면 JPA repository로 응답을 해 user 오브젝트를 돌려준다.

 

12. 그럼 이걸 받아서 user 오브젝트 있다며 다시 service한테 돌려준다.

그럼 service에서 user 오브젝트가 NULL인지 아닌지 체크하면 된다.

user 오브젝트가 NULL이면 로그인이 안 될 것이고,

user 오브젝트가 NULL이 아니면 이런 유저가 있구나 해서

컨트롤러한테 user오브젝트가 NULL이 아니니까 존재하는 사용자다. 로그인을 하면 된다.

 

13. 그래서 세션에 로그인 정보를 등록한다. 이러한 것들을 다 서비스에서 짜놔야 한다.

 

그리고 컨트롤러에서 인증이 필요한 페이지로 이동할 수 있게 도와줘야 한다.

이 때 어떤 컨트롤러인지가 중요하다.

만약 RestController라면 데이터를 응답하는 컨트롤러이고,

이 컨트롤러가 Controller라면 html 페이지를 만들어 사용자에게 응답해주는 컨트롤러이다.

지금은 "/" 페이지로 이동하라고 했으니까 

이것은 데이터를 응답해주는 컨트롤러가 아니라 페이지를 응답해주는 컨트롤러이다.

 

14. 이 때 View Resolver가 작동하게 된다.

View Resolver는 페이지를 만들어서 응답하게 된다.

View Resolver는 일반적인 Controller일 때 항상 작동하게 된다.

 

그러면 인터셉터는 어떤 일을 할까?

예를 들면 1번 유저의 개인정보를 보는 요청이 /user/1 이라고 하자

/user/1 의 함수 실행 직전에 인터셉터가 동작해서

이 함수가 실행되기 전에 지금 들어온 이 사용자가 세션이 있는지를 먼저 확인한다.

user라는 세션이 있는 것을 확인하면 이 user 오브젝트가 1번 유저인지를 확인한다.

확인해서 같은 유저면 그 정보를 보여주고, 다른 유저면 보여주지 않는다.

이런 권한 체크를 미리 할 수 있는 것이 인터셉터이다.

 

필터는 요청이 들어올 때 그 사람을 걸러내는 역할을 한다면

인터셉터는 그 함수가 실행되기 직전에 이 함수가 어떤 개인정보를 주는 응답을 해주는 함수라면

함수 실행 직전에 낚아채서 권한이 있는지를 확인하고 권한이 있다면 데이터를 응답해주는 역할을 한다.

인터셉터를 통해 함수가 실행되기 직전, 실행된 뒤 이럴 때 인터셉터가 요청을 낚아채서 

잠깐 자신이 해야할 일(권한 처리, 인증 처리 등)을 인터셉터에서 하는 것이다.