JavaScript跨域请求解决方案：CORS与JSONP的比较

面试官：什么是跨域请求？为什么会产生跨域问题？

面试者：跨域请求（Cross-Origin Request）是指从一个域名的网页去请求另一个域名的资源。在浏览器中，出于安全考虑，同源策略（Same-Origin Policy）限制了来自不同源的文档或脚本如何与资源进行交互。同源指的是协议、域名和端口都相同。如果这些条件不满足，浏览器就会阻止跨域请求，以防止潜在的安全风险，如XSS攻击。

例如，假设你有一个前端应用 https://example.com，它试图通过AJAX请求访问 https://api.example.org 的数据。由于这两个域名不同，浏览器会根据同源策略阻止这个请求，除非服务器明确允许这种跨域请求。

面试官：那有什么常见的跨域解决方案呢？

面试者：常见的跨域解决方案主要有两种：CORS（Cross-Origin Resource Sharing）和 JSONP（JSON with Padding）。此外，还有其他一些方法，比如使用代理服务器、WebSocket等，但今天我们主要讨论CORS和JSONP这两种最常用的方式。

面试官：请详细解释一下CORS的工作原理。

面试者：CORS 是一种基于 HTTP 头的机制，允许服务器明确指定哪些源可以访问其资源。它的核心思想是通过服务器端设置响应头来告知浏览器是否允许跨域请求。CORS 支持多种HTTP方法（如GET、POST、PUT、DELETE等），并且可以处理复杂的请求，如带有认证信息的请求。

1. 简单请求

对于简单的跨域请求，浏览器不会发送预检请求（Preflight Request），而是直接发送请求。简单请求的条件包括：

请求方法必须是 GET、HEAD 或 POST。
请求头只能包含以下几种：Accept、Accept-Language、Content-Language、Content-Type（且值为 application/x-www-form-urlencoded、multipart/form-data 或 text/plain）。

当客户端发起一个简单的跨域请求时，服务器需要在响应中添加 Access-Control-Allow-Origin 头，以告诉浏览器允许哪个源访问资源。例如：

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Content-Type: application/json

{
  "message": "Hello, World!"
}

在这个例子中，Access-Control-Allow-Origin 设置为 https://example.com，表示只有来自 https://example.com 的请求可以访问该资源。如果设置为 *，则表示所有源都可以访问。

2. 预检请求

对于非简单的跨域请求（例如使用 PUT、DELETE 方法，或者请求头中包含自定义头），浏览器会在实际请求之前发送一个预检请求（OPTIONS 请求），以确认服务器是否允许该请求。预检请求的目的是确保服务器知道即将发送的请求类型，并且能够正确处理。

预检请求的响应中必须包含以下头：

Access-Control-Allow-Methods：允许的HTTP方法。
Access-Control-Allow-Headers：允许的自定义请求头。
Access-Control-Max-Age：预检请求结果的有效期（单位为秒），在此期间浏览器可以缓存预检结果。

例如，假设客户端发送了一个带有自定义头 X-Custom-Header 的 PUT 请求，服务器的响应可能如下：

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Max-Age: 86400

3. 带凭证的请求

默认情况下，CORS 请求是不带凭证的（如 cookies、HTTP 认证信息）。如果需要发送凭证，客户端必须在请求中设置 withCredentials 为 true，并且服务器必须在响应中设置 Access-Control-Allow-Credentials 为 true。例如：

const xhr = new XMLHttpRequest();
xhr.open('GET', 'https://api.example.org/data');
xhr.withCredentials = true;
xhr.send();

服务器的响应头应包含：

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

需要注意的是，当 Access-Control-Allow-Credentials 为 true 时，Access-Control-Allow-Origin 不能设置为 *，而必须是一个具体的源。

面试官：那JSONP的工作原理又是怎样的呢？

面试者：JSONP（JSON with Padding）是一种早期的跨域解决方案，主要用于解决浏览器对 <script> 标签的跨域限制。它的基本思想是利用 <script> 标签可以加载外部资源的特性，将服务器返回的数据包装在一个函数调用中，从而绕过同源策略。

1. JSONP的基本流程

JSONP的工作流程如下：

客户端通过 <script> 标签发起请求，请求URL中包含一个回调函数名作为参数。
服务器接收到请求后，返回一段JavaScript代码，这段代码会调用客户端提供的回调函数，并将数据作为参数传递给该函数。
浏览器执行返回的JavaScript代码，回调函数被调用，客户端可以处理返回的数据。

例如，假设客户端希望从 https://api.example.org 获取数据，并使用 myCallback 作为回调函数，HTML代码可能如下：

<script src="https://api.example.org/data?callback=myCallback"></script>

服务器返回的响应可能是：

myCallback({
  "message": "Hello, World!"
});

浏览器会自动执行这段JavaScript代码，调用 myCallback 函数并传入返回的数据。

2. JSONP的局限性

尽管JSONP可以解决跨域问题，但它也有一些明显的局限性：

仅支持GET请求：由于JSONP依赖于 <script> 标签，而 <script> 标签只能发送GET请求，因此无法使用其他HTTP方法（如POST、PUT、DELETE等）。
安全性问题：JSONP本质上是执行远程服务器返回的任意JavaScript代码，这可能会带来安全风险。如果服务器被恶意控制，攻击者可以通过返回恶意代码来执行跨站脚本攻击（XSS）。
缺乏错误处理：JSONP没有内置的错误处理机制。如果请求失败或服务器返回无效的响应，客户端无法捕获这些错误。
无法携带凭证：JSONP请求无法携带cookies或其他认证信息，因此不适合需要用户登录或认证的场景。

面试官：CORS和JSONP有哪些主要的区别？

面试者：CORS和JSONP的主要区别可以从以下几个方面进行比较：

特性	CORS	JSONP
HTTP方法支持	支持所有HTTP方法（GET、POST、PUT、DELETE等）	仅支持GET请求
安全性	更安全，支持细粒度的跨域控制	存在安全隐患，容易受到XSS攻击
错误处理	支持标准的HTTP错误处理	缺乏错误处理机制
凭证支持	支持携带凭证（如cookies、HTTP认证信息）	不支持携带凭证
浏览器兼容性	现代浏览器广泛支持	老旧浏览器也支持，但已逐渐被淘汰
实现方式	通过HTTP头进行跨域控制	通过 `<script>` 标签加载远程资源
复杂请求支持	支持复杂的跨域请求（如预检请求）	仅支持简单的GET请求

面试官：在实际项目中，你会选择哪种方案？为什么？

面试者：在实际项目中，我通常会选择CORS而不是JSONP，原因如下：

安全性更高：CORS提供了更细粒度的跨域控制，服务器可以通过设置响应头来明确指定哪些源可以访问资源。相比之下，JSONP存在较大的安全风险，因为它允许执行远程服务器返回的任意JavaScript代码，容易受到XSS攻击。
支持更多HTTP方法：CORS不仅支持GET请求，还支持POST、PUT、DELETE等其他HTTP方法，适用于更复杂的API调用场景。而JSONP仅限于GET请求，限制了其应用场景。
更好的错误处理：CORS支持标准的HTTP错误处理机制，客户端可以捕获请求失败的原因并进行相应的处理。JSONP则缺乏有效的错误处理机制，请求失败时难以调试和处理。
支持凭证：CORS允许携带凭证（如cookies、HTTP认证信息），适用于需要用户登录或认证的场景。JSONP则无法携带凭证，限制了其在认证场景中的使用。
现代浏览器的支持：虽然JSONP在老旧浏览器中也有一定的兼容性，但随着浏览器技术的发展，CORS已经成为主流的跨域解决方案。JSONP逐渐被淘汰，不再推荐使用。

面试官：CORS有哪些常见的配置问题？如何解决？

面试者：在使用CORS时，常见的配置问题包括：

跨域请求被拒绝：如果服务器没有正确设置 Access-Control-Allow-Origin 头，浏览器会拒绝跨域请求。解决方法是在服务器端配置正确的响应头，确保允许的源与客户端的源匹配。例如：

Access-Control-Allow-Origin: https://example.com

预检请求失败：对于非简单的跨域请求，浏览器会发送预检请求（OPTIONS 请求），如果服务器没有正确处理预检请求，会导致请求失败。解决方法是在服务器端配置 Access-Control-Allow-Methods 和 Access-Control-Allow-Headers，确保允许的HTTP方法和请求头与客户端的请求一致。例如：

Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: X-Custom-Header

带凭证的请求失败：如果客户端设置了 withCredentials 为 true，但服务器没有设置 Access-Control-Allow-Credentials 为 true，浏览器会拒绝请求。此外，Access-Control-Allow-Origin 不能设置为 *，而必须是一个具体的源。解决方法是在服务器端同时设置 Access-Control-Allow-Credentials 和 Access-Control-Allow-Origin。例如：

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

跨域资源共享范围过大：如果 Access-Control-Allow-Origin 设置为 *，意味着任何源都可以访问该资源，这可能会带来安全风险。建议根据实际情况限制允许的源，只允许特定的域名访问资源。
缓存问题：预检请求的结果会被浏览器缓存一段时间（由 Access-Control-Max-Age 头控制），如果缓存时间过长，可能会导致客户端无法及时获取最新的跨域配置。解决方法是根据业务需求合理设置 Access-Control-Max-Age，避免缓存时间过长。

面试官：总结一下，CORS和JSONP各自的优缺点是什么？

面试者：总结来说，CORS和JSONP各有优缺点：

CORS：
- 优点：支持所有HTTP方法，安全性高，支持细粒度的跨域控制，支持凭证，错误处理机制完善，现代浏览器广泛支持。
- 缺点：配置较为复杂，尤其是对于复杂的跨域请求（如预检请求），需要服务器端进行额外的配置。
JSONP：
- 优点：实现简单，兼容性好（即使是老旧浏览器也支持），不需要服务器端进行复杂的配置。
- 缺点：仅支持GET请求，存在安全隐患，缺乏错误处理机制，无法携带凭证，逐渐被淘汰。

在现代Web开发中，CORS已经成为主流的跨域解决方案，而JSONP由于其局限性和安全隐患，已经逐渐被淘汰。