- API 통신과 백엔드 작업에 대하여
- API 통신시 헤더 활용하기 (현재글)
들어가며
지난 시간 백엔드의 기본적인 프로세스와 데이터베이스에 대하여 알아보았다.
이번시간에는 프론트엔드에서 백엔드로 요청을 보낼 때 헤더에 인증값 등을 헤더에 보내는 동작들에 대해 알아보는 시간을 가져보도록 하겠다
헤더를 사용하는 이유?
API 통신을 하다 보면 로그인 후 헤더에 토큰값을 실어 통신을 해야 하는 경우 많이 있다.
예를 들어 사용자가 로그인 후 내가 구매한 상품의 정보를 얻는다던가, 혹은 사용자 정보를 수정하는 등의 기능들은 권한이 부여된 사용자에게만 기능을 제공해야 한다.
아이디와 비밀번호 체크만으로 해결할 수 있지 않느냐는 의문이 있을 수 있지만, 비밀번호의 경우 복호화나 해킹을 통한 암호변경의 가능성이 있으며, 이럴 경우 권한이 있는지에 대한 확인이 없으면 정보탈취가 가능하게 된다.
현재 진행 중인 프로젝트에서는 Spring Security와 외부 연동기능을 사용하고 있기 때문에 이를 기반으로 설명하도록 하겠다.
권한인증에 대하여
Spring Security에서는 로그인 이전의 동작과 로그인 이후의 동작에 대해 제어를 한다.
여기서 이야기 하는 제어란 로그인을 해야 API(url)에 접근 할 수 있고 로그인을 하지 않으면 로그인 페이지로 이동하는 것을 말한다.
로그인을 했더라도 헤더에 인증정보를 넣어서 보내지 않으면 리턴이 에러로 반환된다.
Ajax통신으로 요청을 보내는 방법은
와 같은 방법으로 요청을 보내면 된다.
위 예시는 외부API 인 네이버 페이 연동 으로 살펴볼 부분은 beforeSend 부분인데, xhr.setRequestHeader 으로 키와 값을 세팅해준다.
키와 값의 정보는 content-type 이나 Authorization 등 다른 정보들을 심어줄 수도 있다.
만약 토큰이나 인증정보를 심어주지 않고 요청을 보내면 서버는 어떤 결과를 반환하는지에 대해서도 함께 알아보도록 하겠다.
인증을 무시할 경우
다음은 헤더에 토큰정보를 보냈을 경우와 보내지 않았을 경우 반환되는 네트워크 리턴정보 이다.
(토큰정보를 보낸 네트워크 요청 결과)
(토큰정보를 안 보낸(혹은 로그인 안 한) 네트워크 요청 결과)
토큰을 보내지 않거나 정상적이지 않은 토큰을 보냈을 경우 에러코드는 400(403)번대 에러이다.
403 에러는 권한 없음 에러로 서버에서는 특정 권한이 있어야 제공해주는 정보들에 대해 인증정보를 보내지 않거나 잘못된 인증 정보를 요청받아 허용되지 않은 요청 에러인 403 에러를 반환하는 것 이다.
postman등의 프로그램을 통해 테스트를 해야 한다면 로그인처리를 먼저 한 후 리턴받은 토큰값을 따로 저장하고 있다가 해당값을 헤더에 심어서 보내면 제한적으로나마 테스트가 가능하다.
만약 API 정의서 문서양식대로 헤더와 body에 값을 심어보냈는데 에러가 발생했다면 문서가 현행화 되어있지 않거나 혹은 오타가 있을 수 있다.
(현재 프로젝트에서 현행화 되어있지 않은 문서를 제공한 업체로 인해 상당한 시간을 날려버리는 일이 발생하기도 하였다) 제일 좋은 방법은 백엔드서버를 디버그모드로 로컬에서 돌리면 명확하게 확인이 가능하며, 그러한 상황이 되지 못할 경우에는 직접 서버개발자에게 크로스체킹을 요청하거나, 원겨리일 경우 이메일로 보낸 요청 정보와 리턴정보를 캡처 후 확인요청을 하여 잘못된 부분을 해결할 수 있다.
(API 정의서 양식은 이전 포스팅 글에서 일부 예시가 있으니 그 부분을 참고해보자)
마치며
이번시간에는 인증정보를 보내야 하는 이유와 방법에 대해 알아보았다 프로젝트를 진행하다 보면 한 번쯤은 경험하게되는 인증에 대해 모두가 어려워하지 않고 편하게 작업할 수 있기를 바라며 이글을 마친다.