1.SOP(same-origin-policy)
: 동일한 출처에 대한 정책 , 동일한 출처에서만 리소스 공유 가능 => 보안을 위해서 생긴 정책
**동일한 출처?
이 세가지가 동일한 것을 동일한 출처라고한다. 이 출처의 비교를 통해서 차단을 할지 말지 결정을 한다.
그러나 다른 출처에서의 리소스가 필요할 경우가 많기 때문에 cors가 생겼다.
참고사항❗️
출처비교를 통한 차단은 서버쪽에서하는것이 아닌 브라우저가 한다!
2.CORS(cross-origin-resource-sharing)
CORS에러라고했지만 위의 SOP의 해결책으로 나온 것이 cors라고 생각하면된다.
방법
1. client : request시 HTTP헤더에 Origin을 담아 전달한다.
*origin: http://localhost:3000
2.server: Access-Control-Allow-Origin을 응답헤더에 추가하여 이 리소스 접근을 허용하는 출처 URL을 적어준다.
=>위의 2과정을 거쳐서 응답을 받은 브라우저가 요청origin과 서버응답의 access를 비교하여 차단 결정을 내린다.
나의 경우에는 서버작업을 할 수 없는 상황이였다.
금융감독원의 openAPI를 사용하고 있었고, 서버에 localhost를 추가할 수 없는 상황이였다. 그래서 사용한 방법이 proxy서버 였다.
proxy: client와 server사이의 중계 대리점(?)-> 모든 출처를 허용한 서버대리점을 통해서 요청
**heroku와 같은 무료프록시 서버 대여 서비스들은 모두 악용사례때문에 api 요청 횟수 제한을 두어 실전에서는 사용하기 무리이다.
=> react-query를 사용해서 실시간으로 데이터를 여러번 요청하면 제한이 걸려서 데이터를 가져오지 못한 이유
proxy서버의 장점 ✅
1.요청받은 data를 캐시하여 -> 같은 요청 시 캐시에 있는 값을 준다 (시간절약)
2.보안 : IP주소를 숨길 수 있다.
3.접속우회 가능 : 주소를 우회할 수 있다. -> 나는 이 경우를 통해서 데이터를 가져올 수 있었다.
진행상황
프로젝트를 진행하면서 데이터를 파이어베이스에 내재화하기로 했다. react-query를 사용해서 데이터를 가져오려던 것을 axios를 이용해서 단순히 한번만 가져오도록 했다.
그 이유는 react-query의 경우 실시간 데이터를 가져오는데 유용하지만, 우리의 경우는 데이터가 고정된 금융api였고, 한 번 가져온 것으로 해결을 볼 수 있기 때문에 굳이 react-query를 고집하지 말자고 판단을 내렸다.
그 대신 안정적인 데이터 호출을 위해서 axios로 가져온 데이터를 파이어베이스에 내재화하는 방법을 택하면서 프록시에 대한 불편함을 없앨 수 있었다.
'TIL✨' 카테고리의 다른 글
TIL-간단한 debounce (0) | 2023.03.04 |
---|---|
마이페이지 유효성 검사 (0) | 2023.03.03 |
중간발표 TIL (0) | 2023.03.02 |
TIL (1) | 2023.02.23 |
데이터가져오기 변경....TIL (0) | 2023.02.18 |