cors 에러 해결-1

포기하지 않으면 불가능은 없다!

(하지만 포기하면 편하겠지..?)

 

 

일단 저번에 쓴 글에서 얼렁뚱땅 넘어간 cors 에러를 해결해보려고 한다. 아래 링크로 가면 왜 앱 개발하고 있는 내가 cors 에러를 맞닥뜨리고 해결하려고 하는지 알 수 있다. 

https://heenano.tistory.com/8

 

 

이번 이슈는 거의 일주일 동안 붙잡고 있었던 , 내가 해결하려는 모든 문제 중에 가장 지치고 오래걸렸지만 그만큼 해결하고 난 뒤의 희열도 남달랐던 그런 이슈다. (뿌듯함이 이루 말할 수 없다.) 참고로 해결하기까지 오래 걸린만큼 산넘어 산이었다. 하나를 해결하면 다른 하나가 생겨났고 그걸 해결하면 다른 하나가 또 생기고.. 그러다 다시 원점. 이 무한굴레를 반복적으로 돌면서 이슈가 생긴 원인 파악에 집중하면서 나아갔다.

 

동일 출처 정책  Same-Origin Policy [SOP]

동일 출처 정책은 웹 브라우저 보안을 위해 프로토콜, 호스트, 포트가 동일한 서버로만 요청을 주고 받을 수 있도록 한 정책이다. 한마디로 “동일한 출처(origin)“에서만 리소스를 공유할 수 있게끔 제한한다는 얘기다.

 

교차 출처 리소스 공유 정책  Cross-Origin Resource Sharing [CORS]

CORS 정책은 SOP의 제한을 우회하여, 한 출처에서 로드된 웹 애플리케이션이 다른 출처의 리소스에 접근할 수 있게 해주는 메커니즘이다. 동일한 출처가 아니더라도 헤더에 적정 값을 넣어서 요청을 하면 리소스 공유를 할 수 있다.

 

CORS error

웹 애플리케이션이 다른 출처(origin)에서 리소스를 요청할 때 발생할 수 있는 보안 관련 문제이다. 브라우저가 SOP(Same-Origin Policy)를 적용할 때 발생하며 CORS는 이러한 제한을 우회하는 방법을 제공하지만, 올바르게 설정되지 않으면 cors 에러가 발생한다.

 

 

일단 구글링 하면 나오는 일반적인 cors 에러해결법을 말하자면 아래와 같다. 더 많은 방법이 있지만 일단 대표적으로 해결하는 방법들이다.

 

1. 서버 측 설정 변경

서버에서 CORS 헤더를 설정하여 특정 도메인 또는 모든 도메인에서의 요청을 허용

2. 프록시 서버 사용

프론트엔드와 백엔드 사이에 프록시 서버를 두어 CORS 문제를 해결

3.브라우저 확장 프로그램 사용

개발 중에는 브라우저 확장 프로그램을 사용하여 CORS 문제를 임시로 해결 (ex. Chrome의 CORS Unblock 확장 프로그램)

4.  Same Origin Policy 적용

가능하다면 동일한 도메인, 포트, 프로토콜을 사용하여 CORS 문제를 원천적으로 방지

 

 

내 상황에서는 2번이 베스트였다. 지금 백엔드 개발자 분은 쉬고 계시기 때문에 1번은 불가능했다. 4번의 경우 -> 물론 지금은 백엔드 서버가 로컬 서버로 Docker에서 실행중이고 나중에 출시 할때쯤엔 도메인을 구매해서 사용하니 추후에 손쉽게 해결할 수 있는 방법이다. 하지만 애초에 앱을 웹으로 띄워서 배포한 목적은 내가 개발하고 있는 진행상황을 다른 개발자 분들도 확인 할 수 있게 하기 위해서기 때문에 출시가 된 이후에 해결을 하려고 하기엔 늦다. 따라서 3번의 동일 출처 정책을 적용하지 않는 브라우저 확장 프로그램을 사용하여 개발 상황을 확인 하거나 2번 프록시 서버를 사용하여 cors 에러를 해결하는 방법을 적용해야 했다.

 

결과적으로 나는 프록시 서버를 구축해보기로 했다. 근본적으로 발생하는 문제를 얼렁뚱땅? 피하고 싶지 않았고 나중에 내가 개발자로 일하면서 분명 마주할 문제라고 생각해서 이번에 해결하고 넘어가면 꼭 도움이 될것 같았기 때문이다.

 

 

프록시 서버 구축하기

1. Nginx 설치

2. Nginx 테스트

3. nginx.conf 파일 수정

 

 

1. Nginx 설치 

$brew install nginx

위의 명령어를 통해 homebrew로 nginx 를 설치한다. Mac을 사용할시에는 homebrew를 사용하여 설치해야 해서 설치 경로가 우분투/리눅스로 설치할때랑 다를것이니 경로에 유의하여야 한다.

 

2. Nginx 테스트

$brew services start nginx

그러면 아래와 같은 default html 파일이 로드된다. 

 

 

3. nginx.conf 파일 수정 

$ sudo vi /opt/homebrew/etc/nginx/nginx.conf
$ sudo nginx -t
$ sudo brew services reload nginx

nginx.conf 파일을 찾아서 안의 내용을 수정해야한다. 수정한 후 설정 파일 유효성 검사를 한 후 nginx relaod 또는 restart를 하면 된다. (보통 homebrew로 설치하면 /opt/homebrew/etc/nginx 안에 있다.)

 

# 해당 파일

worker_processes 1;

events {
	worker_connections 1024;
}

http {
	include mime.types;
	server {
		listen 80;
		location / {
			root html;
			index index.html index.htm;
		}
	}
}

 

• woker_processes 
  • Nginx가 동시에 실행할 수 있는 워커 프로세스(worker process)의 수를 설정하며 서버의 동시 처리 능력에 직접적인 영향을 미친다.
• events 블럭의 worker_connections
  • 각 워커 프로세스가 동시에 처리할 수 있는 최대 연결 수를 설정한다. 이 값은 각 워커 프로세스가 동시에 얼마나 많은 클라이언트 연결을 처리할 수 있는지를 결정한다.

• server 블록
  •  하나의 웹사이트를 선언하는데 사용된다. server 블록을 여러개 설정할 수도 있는데 가상 호스트 개념으로 listen 뒤의 포트 다르게 설정하여 여러 웹사이트를 서빙할 수 있다. 실제로 호스트는 한대지만, 가상으로 마치 호스트가 여러개 존재하는 것처럼 동작하게 할 수 있다.
• location 블록
  •  server 블록안에 등장해서, 특정 웹사이트의 url 을 처리하는 데 사용한다. 

 

 

 

내 개발 상황에 맞게 수정하기만 하면 되는데.. 약간의 문제가 있다. 내가 github를 통해서 배포한 내 웹페이지 프로토콜이 https인것이다. 

(https는 SSL/TLS를 사용하여 데이터를 암호화하기 때문에 ssl 증명서와 key를 따로 발급받아야 한다.)

 

server {
    listen 443 ssl;
    server_name www.example.com;

    #ssl_certificate directory
    ssl_certificate      /opt/homebrew/etc/nginx/ssl; 
    #ssl_certificate key
    ssl_certificate_key  /opt/homebrew/etc/nginx/ssl;

    ssl_session_timeout  5m;
    ssl_ciphers  HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers  on;
	ssl_protocols TLSv1.2 TLSv1.3;


    location / {     
    }        
}

 

그래서 발급받은 인증서와 키는 이런식으로 적용을 해야 한다. 

 

 

이후의 해결방법은 너무 길어져서 2탄에서 설명을 해야겠다.

 

cors 에러 해결방법 -2탄

https://heenano.tistory.com/10

cors 에러 해결-2