jsonp 크로스 도메인을 사용하는 것은 권장되지 않습니다. 이 고대 방법은 호환성이 좋지만 제한 사항이 크고 XSS의 위험이 있습니다. 프런트엔드와 백엔드를 완전히 분리하려면 물론 웹 서버를 관리하는 프런트엔드 인력이 필요합니다. 물론 프런트엔드 인력에 대한 요구 사항도 더 높습니다.
단순히 인터페이스를 조정하는 것이라면 로컬 테스트 서버를 직접 설정하는 것이 좋습니다. 페이지 조정에 편리하고 요청 및 요청을 전달할 수 있는 페이지용 정적 서버로 사용됩니다. 데이터. 직접 표현을 사용할 수도 있고, browsersync+gulp 또는 webpack+hot reload 서버와 같이 이미 만들어진 것을 사용할 수도 있습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
백그라운드에서 response.setHeader("Access-Control-Allow-Origin", "*"); 설정
문제를 해결하기 위해 nginx 측에서 구성할 수도 있습니다.
jsonp는 특별히 좋은 방법은 아니며 전송되는 데이터에 크기 제한이 있습니다.
CORS。。。。
CORS. 프론트엔드, 백엔드 분석이므로 헤더만 백그라운드로 설정해주세요
이번에는 노드 서버를 사용하여 요청을 전달합니다
jsonp 크로스 도메인을 사용하는 것은 권장되지 않습니다. 이 고대 방법은 호환성이 좋지만 제한 사항이 크고 XSS의 위험이 있습니다.
프런트엔드와 백엔드를 완전히 분리하려면 물론 웹 서버를 관리하는 프런트엔드 인력이 필요합니다. 물론 프런트엔드 인력에 대한 요구 사항도 더 높습니다.
단순히 인터페이스를 조정하는 것이라면 로컬 테스트 서버를 직접 설정하는 것이 좋습니다. 페이지 조정에 편리하고 요청 및 요청을 전달할 수 있는 페이지용 정적 서버로 사용됩니다. 데이터.
직접 표현을 사용할 수도 있고, browsersync+gulp 또는 webpack+hot reload 서버와 같이 이미 만들어진 것을 사용할 수도 있습니다.
저는 browsersync를 사용하는데 구성이 매우 편리하니 참고하시면 됩니다.
chrome 플러그인이 있는데, response.setHeader("Access-Control-Allow-Origin", "*") 기능을 수행합니다. 켜기만 하면 됩니다.
nginx 추가
WebSocket은 도메인 간 제한이 적용되지 않으며 jsonp를 포함한 모든 데이터를 전송할 수 있습니다.
그런데 이건 개발 전에 결정해야 하는 것 아닌가요? 공동 디버깅 전까지 jsonp인지 cors인지 판단하기에는 조금 늦은거 아닌가요?
jsonp가 필요없어 너무 불편해요