本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

简介：在Web开发中，同源策略常导致不同源的请求被阻止，尤其在前后端分离的项目中。本文将介绍如何通过配置Tomcat服务器的CORS机制，允许跨域请求，详细说明了CORS的原理和在Tomcat中的配置步骤，包括CORS过滤器的使用和参数配置，以及通过Nginx进行反向代理的方法。
Tomcat跨域

1. 同源策略介绍

在探讨前端开发和后端服务的交互中，我们不得不先了解一个关键的网络安全机制——同源策略（Same-Origin Policy）。同源策略是浏览器安全的基石，它限制了来自不同源（协议、域名或端口）的文档或脚本如何相互交互。本章将带领读者了解同源策略的定义、历史以及它的核心作用。

1.1 同源策略的定义

同源策略是一种限制脚本如何从一个源访问另一个源资源的机制。它规定，只有当两个URL的协议、域名和端口都相同时，这两个URL才被认为是同源的。如果它们不同源，则称彼此为跨源（cross-origin）。例如，http://www.example.com上的页面尝试加载http://www.anotherdomain.com上的资源时，就会触发同源策略的限制。

1.2 同源策略的历史背景

同源策略的概念最早由浏览器厂商提出，旨在解决一个核心问题：如何在一个开放的网络环境中保护用户的数据安全。通过限制不同源之间的数据交换，同源策略防止了恶意脚本获取或修改其他网站的数据，为用户提供了一个更为安全的浏览环境。

1.3 同源策略的核心作用

同源策略的核心作用是隔离不同源的文档交互，以防止恶意网站窃取信息。它为不同的网站设立了独立的空间，使得开发者必须使用适当的技术或策略来实现跨域数据共享，而不是毫无限制地访问其他域的内容。在随后的章节中，我们将深入了解如何在遵循同源策略的前提下实现跨域资源共享（CORS），这是现代Web开发中常见的挑战之一。

2. CORS跨域资源共享机制

2.1 CORS基本原理

2.1.1 同源策略与跨域限制

同源策略是浏览器的一种安全机制，用于限制一个源的文档或脚本如何与另一个源的资源进行交互。当两个URL的协议、端口（如果指定了的话）以及域名相同，则它们被认为是同源的。同源策略防止了恶意网站窃取数据和其他安全问题，但同时也限制了Web应用中的一些正常功能。

跨域限制指的是当一个Web页面试图通过XMLHttpRequest或其他方式访问另一个域的资源时，出于安全考虑，浏览器会限制这种跨域HTTP请求。例如，如果你的前端应用运行在 http://www.example.com ，尝试获取 http://www.anotherdomain.com 上的资源时，就会遇到跨域问题。

2.1.2 CORS解决跨域问题的核心思路

CORS（Cross-Origin Resource Sharing，跨源资源共享）是一种允许当前域的Web应用访问另一个域资源的机制。它通过在HTTP头中添加一些信息来告诉浏览器，服务器允许来自特定域的访问。这一机制的背后核心思想是，在服务端声明对哪些来源的跨域请求提供支持，而浏览器在接收到这些声明后，会决定是否允许前端代码去发起跨域请求。

具体来说，当浏览器发起一个跨域请求时，会在HTTP请求中加入一个Origin头，告诉服务器这个请求是从哪里发起的。如果服务器愿意处理这个请求，它会在响应的HTTP头中加入 Access-Control-Allow-Origin 字段，表明允许哪些域的请求。如果请求被拒绝，浏览器将阻止前端JavaScript代码访问这个响应。

2.2 CORS的实现机制

2.2.1 简单请求与复杂请求的区别

简单请求和复杂请求是根据是否需要预检请求（Preflight）来区分的。简单请求满足以下两个条件：

  • 请求方法是以下三种方法之一：GET、POST、HEAD。
  • HTTP头字段不超过以下几种：
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type （限于 application/x-www-form-urlencoded 、 multipart/form-data 和 text/plain ）

不满足以上条件的请求被认为是复杂请求，浏览器会先发送一个OPTIONS请求到服务器作为预检，以确认实际请求是否安全可接受。

2.2.2 预检请求（Preflight）机制详解

预检请求是CORS机制中用于提高安全性的一种方式。在发起实际的跨域请求之前，浏览器会首先发送一个OPTIONS请求到同一服务器上的目标URL。这个预检请求会包含一些信息，特别是 Access-Control-Request-Method 和 Access-Control-Request-Headers 头，分别用于告知服务器实际请求将使用哪些HTTP方法和头信息。

如果服务器允许该请求，则会返回一个带有相应CORS头的响应，如 Access-Control-Allow-Origin 和 Access-Control-Allow-Methods 等，以及一个 Access-Control-Allow-Headers 头，明确指出允许的头信息。一旦预检请求通过，实际的请求才会被发送。

服务器的响应头中也会包含一些字段，如 Access-Control-Allow-Credentials 和 Access-Control-Allow-Origin ，允许或者限制凭证信息（如Cookies和授权头部）被发送。如果预检请求失败，浏览器不会执行实际的跨域请求。

上述章节内容为《第二章：CORS跨域资源共享机制》的概述，接下来的章节将继续深入介绍如何配置CORS策略以实现跨域资源共享，包括在Tomcat中配置CORS、使用CORS过滤器库以及处理预检请求等关键细节。

3. Tomcat配置CORS的方法和参数说明

在本章节中，将详细介绍如何在Tomcat服务器上配置CORS以允许跨域请求。这将涵盖在web.xml中进行配置，以及通过Java代码进行设置的具体步骤。同时，本章还会深入探讨CORS响应头参数的含义和作用，确保读者能够理解并正确应用这些参数。

3.1 Tomcat中的CORS配置方法

3.1.1 在web.xml中配置CORS

要在Tomcat的web.xml中配置CORS，您需要在该文件中添加特定的过滤器和过滤器映射。以下是一个基本的配置示例： 

<filter>
  <filter-name>CorsFilter</filter-name>
  <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
  <init-param>
    <param-name>cors.allowed.origins</param-name>
    <param-value>*</param-value>
  </init-param>
  <init-param>
    <param-name>cors.allowed.methods</param-name>
    <param-value>GET,POST,HEAD,OPTIONS,PUT</param-value>
  </init-param>
  <init-param>
    <param-value>cors.allowed.headers</param-value>
    <param-value>Content-Type,X-Requested-With,accept,Authorization</param-value>
  </init-param>
  <init-param>
    <param-name>cors.exposed.headers</param-name>
    <param-value>Access-Control-Allow-Origin,Access-Control-Allow-Credentials</param-value>
  </init-param>
  <init-param>
    <param-name>cors.support.credentials</param-name>
    <param-value>true</param-value>
  </init-param>
  <init-param>
    <param-name>cors.preflight.maxage</param-name>
    <param-value>10</param-value>
  </init-param>
</filter>

<filter-mapping>
  <filter-name>CorsFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

此配置会启用CORS，并允许来自任何源的所有请求方法。 cors.allowed.headers 参数列出了服务器将会接受的请求头，而 cors.exposed.headers 参数则指示服务器会将哪些响应头暴露给前端应用。 cors.support.credentials 参数设置为 true 表示支持凭证传输。

3.1.2 使用Java代码配置CORS

通过Java代码配置CORS涉及到在您的Web应用程序中实现一个 Filter ，并在 doFilter 方法中添加CORS相关的逻辑。下面是一个简单的例子： 

import javax.servlet.*;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

public class SimpleCorsFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
    }

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
        throws IOException, ServletException {
        HttpServletResponse response = (HttpServletResponse) res;
        response.setHeader("Access-Control-Allow-Origin", "*");
        response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE");
        response.setHeader("Access-Control-Max-Age", "3600");
        response.setHeader("Access-Control-Allow-Headers", "x-requested-with");

        chain.doFilter(req, res);
    }

    @Override
    public void destroy() {
    }
}

上述代码定义了一个简单的CORS过滤器。它通过设置 Access-Control-Allow-Origin 为 * 来允许任何源访问资源。同时，它还设置了其他CORS相关的响应头。这种方式比在web.xml中配置更加灵活，允许您在运行时动态决定CORS策略。

3.2 CORS相关参数介绍

3.2.1 Access-Control-Allow-Origin参数

Access-Control-Allow-Origin 是最为关键的CORS响应头。它指示哪些来源可以访问资源。该参数可以设置为具体的域名或者使用 * 表示接受所有域名。

3.2.2 Access-Control-Allow-Methods参数

Access-Control-Allow-Methods 定义了允许的HTTP方法。当预检请求返回时，它告诉浏览器服务器允许的HTTP操作。例如，设置 Access-Control-Allow-Methods 为 GET, POST, OPTIONS 将允许这三种方法被跨域调用。

3.2.3 其他CORS响应头参数详解

CORS还支持其他响应头参数，包括：

  • Access-Control-Allow-Headers : 定义允许的请求头字段，当预检请求的 Access-Control-Request-Headers 包含非简单请求头时需要此参数。
  • Access-Control-Allow-Credentials : 为 true 时，表示可以携带凭证（如cookies）。
  • Access-Control-Expose-Headers : 指示哪些额外的响应头可以被前端JavaScript访问。
  • Access-Control-Max-Age : 指定预检请求结果的缓存时间。

正确的配置这些参数可以解决大部分的跨域问题，并为前端提供安全、灵活的跨域访问能力。

4. CORS过滤器库的使用

在现代Web开发中，处理CORS问题已成为前端与后端开发者经常遇到的挑战之一。CORS过滤器库的使用可以极大简化这一过程，因为它提供了一种集中式的方式来管理跨域请求，无需修改现有的业务代码，且易于配置和维护。下面将详细探讨使用CORS过滤器库的优点，以及如何配置和使用这些过滤器。

4.1 使用CORS过滤器的优点

4.1.1 无需修改应用代码

CORS过滤器库的一个显著优势是，它允许开发者在不需要修改现有应用程序代码的情况下解决跨域问题。这在大型项目中尤其有价值，因为修改业务逻辑代码可能会引入新的bug或者需要进行繁琐的回归测试。

4.1.2 简化配置，提高灵活性

通过使用CORS过滤器库，可以集中管理CORS相关的配置，而不是分散在多个地方或在代码中硬编码。这意味着，如果有跨域规则变更，只需修改过滤器的配置即可，大大提高了配置的灵活性和可维护性。

4.2 CORS过滤器的配置与使用

4.2.1 添加CORS过滤器库依赖

大多数CORS过滤器库都是作为第三方库提供，可以通过项目构建工具（如Maven或Gradle）添加到项目中。例如，在Maven项目中，添加一个依赖可能如下所示： 

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

确保选择的库支持当前使用的Web框架版本。

4.2.2 配置CORS过滤器参数

一旦添加了依赖，接下来需要配置过滤器参数以满足应用需求。配置方式依赖于所选的CORS过滤器库，但通常涉及指定允许的源、方法和头部等。以下是一个配置Spring Security CORS过滤器的示例： 

@Bean
public CorsFilter corsFilter() {
    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    CorsConfiguration config = new CorsConfiguration();
    config.setAllowCredentials(true);
    config.addAllowedOrigin("*");
    config.addAllowedHeader("*");
    config.addAllowedMethod("*");
    source.registerCorsConfiguration("/**", config);
    return new CorsFilter(source);
}

在这个例子中，我们创建了一个 CorsFilter bean，允许来自任何源的跨域请求，并允许使用任何HTTP方法和头部。

4.2.3 过滤器应用示例

以下是一个简单的Java Web应用程序，展示了如何在Spring Boot应用中应用上述配置。此示例同时使用了一个简单的Spring MVC控制器，用于处理HTTP GET请求。 

@RestController
public class HelloWorldController {
    @GetMapping("/hello")
    public String hello() {
        return "Hello, CORS!";
    }
}

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

在这个应用中，任何尝试访问 /hello 的跨域请求都将通过我们之前配置的CORS过滤器。如果配置正确，前端应用（假设在不同的源上运行）将能够成功接收到响应数据。

以上步骤展示了如何通过CORS过滤器库解决跨域问题，并且能够看到它如何能够为开发者提供方便快捷的解决方案，而不干扰现有的业务逻辑。随着Web技术的发展，CORS过滤器的使用变得更加普遍，它们使得跨域问题的解决变得更加简单和高效。

5. 预检请求的理解和处理

5.1 预检请求的触发条件

5.1.1 触发预检请求的HTTP方法

在CORS策略中，预检请求主要由特定的HTTP方法触发。通常情况下，非简单请求会被浏览器视为潜在的跨域请求，因此在实际发送请求前，浏览器会先发送一个预检请求（也称为options请求）。非简单请求包括：

  • 使用了PUT、DELETE、CONNECT、OPTIONS、TRACE、PATCH等HTTP方法。
  • 使用了自定义头部（例如， X-Custom-Header ）。
  • 使用了非简单头部，比如 Content-Type 不是 application/x-www-form-urlencoded 、 multipart/form-data 或 text/plain 。

这种机制确保了当服务器端未正确配置以允许跨域请求时，浏览器不会发送真正的请求，从而保护了服务器端资源。

5.1.2 触发预检请求的HTTP头字段

除了特定的HTTP方法外，某些HTTP头部字段的使用也会触发预检请求。典型的触发头字段如下：

  • Content-Type ：如果设置为非简单类型，比如 application/json 或自定义类型，会触发预检。
  • Access-Control-Request-Headers ：在实际请求中包含的自定义请求头字段，在预检请求中被浏览器列出，请求服务器授权。

5.2 如何处理预检请求

5.2.1 配置允许的请求头

处理预检请求的第一步是在服务器端配置允许的HTTP请求头。这通常涉及到设置 Access-Control-Allow-Headers 响应头。例如，如果我们想允许 X-Custom-Header 和 X-Other-Header ，我们可以在服务器端添加如下响应头： 

Access-Control-Allow-Headers: X-Custom-Header, X-Other-Header

代码块中配置了允许的HTTP请求头，确保这些头能被跨域请求使用。在实际操作中，开发者需要根据前端实际需求添加相应的请求头名称。

5.2.2 配置允许的方法和凭证

在配置了允许的请求头后，需要明确告诉浏览器允许哪些HTTP方法。这通过设置 Access-Control-Allow-Methods 响应头来实现。例如，允许GET、POST和PUT方法： 

Access-Control-Allow-Methods: GET, POST, PUT

此外，如果跨域请求需要发送凭证（如cookies和授权头部），则必须显式设置 Access-Control-Allow-Credentials 为 true 。同时， Access-Control-Allow-Origin 不能设置为 * ，必须指定具体的源。

5.2.3 处理预检请求失败的情况

当预检请求失败时，浏览器通常不会发送实际的跨域请求，因此，处理预检请求失败是确保跨域资源共享正常工作的关键。开发者可以通过审查预检请求的响应来诊断问题，常见的问题包括：

  • 服务器未返回 Access-Control-Allow-* 相关头部。
  • Access-Control-Allow-Origin 配置错误，比如允许了 * 但是浏览器传入了具体的源地址。
  • 服务器返回了错误代码，如5xx系列的服务器错误，或4xx系列的客户端错误。

要解决这些问题，开发者需要确保服务器端正确配置了CORS相关的响应头。开发者可以通过调试工具（如Chrome开发者工具的Network面板）查看预检请求和响应的详细信息。 

graph LR;
    A[触发预检请求] --> B[服务器配置响应头];
    B --> C{预检成功};
    B --> D[预检失败];
    C --> E[发送实际请求];
    D --> F[停止请求流程];
    F --> G[检查服务器配置];
    G --> B;

通过上述流程，我们能更好地理解预检请求的触发条件和处理方式，这对于确保应用的跨域资源共享策略正确实施至关重要。

6. JSONP技术在特定条件下的应用

JSONP（JSON with Padding）是一种在受限的环境中（比如不同域的Web服务器之间）传递JSON数据的方法。它利用了 <script> 标签的跨域特性，因为 <script> 标签加载资源时不受同源策略限制。我们将从JSONP的工作原理和实现方法展开讨论，以及在使用中需要注意的安全性问题。

6.1 JSONP技术原理

6.1.1 JSONP的工作机制

JSONP的核心思想是通过动态创建 <script> 标签的方式，绕过浏览器的同源策略。具体流程如下：

  1. 客户端在当前域下发起一个请求到服务端，请求的URL中包含一个回调函数名（例如 callback=showData ）。
  2. 服务端响应时，将数据用客户端提供的回调函数名进行封装，构造一个函数调用的形式（如 showData(jsonData) ），并将这段脚本返回给客户端。
  3. 客户端接收到脚本后执行，从而获得了跨域的数据。

示例代码： 

// 客户端请求
var url = 'http://example.com/data?callback=myCallback';
var script = document.createElement('script');
script.src = url;
document.body.appendChild(script);

// 客户端回调函数
function myCallback(data) {
    console.log('Data from server:', data);
}

// 服务端响应
myCallback({name: 'JSONP', message: 'Data received!'});

6.1.2 JSONP的优缺点分析

优点:

  • 简单易实现，不需要服务端支持CORS。
  • 跨浏览器兼容性良好。

缺点:

  • 只支持GET方法，不能处理POST或其他HTTP方法。
  • 安全性较差，容易受到跨站脚本攻击（XSS）。
  • 回调函数名只能由服务端提供，存在潜在的冲突问题。

6.2 JSONP的实现和注意事项

6.2.1 前端JSONP请求的编写

前端代码需要动态创建 <script> 标签，并处理来自服务端的数据。 

// 前端创建JSONP请求
function createJSONPRequest(url, callback) {
    var script = document.createElement('script');
    script.src = url + (url.indexOf('?') > 0 ? '&' : '?') + 'callback=' + callback;
    document.getElementsByTagName('head')[0].appendChild(script);
}

// 定义回调函数
function myCallbackFunction(response) {
    console.log('Response:', response);
}

// 发起JSONP请求
createJSONPRequest('http://example.com/data', 'myCallbackFunction');

6.2.2 后端JSONP响应的设置

后端需要识别请求中的回调函数名，并构造相应的JavaScript代码返回。 

// 假设使用Java后端，简单示例
String callback = request.getParameter("callback");
String response = callback + "(" + yourJsonObject.toString() + ");";
out.print(response);

6.2.3 安全性考虑与限制

为了减少安全风险，必须对返回的数据进行严格的过滤，避免执行恶意代码。同时，尽量避免使用全局的回调函数名，可以采用更复杂的命名策略，减少命名冲突和提高安全性。

JSONP作为跨域的解决方案在特定场景下仍然有其应用价值，但在使用中需要考虑到它的局限性和安全性问题。开发者应该在评估了其他更安全的跨域解决方案（如CORS）之后，再决定是否使用JSONP。

本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

简介：在Web开发中，同源策略常导致不同源的请求被阻止，尤其在前后端分离的项目中。本文将介绍如何通过配置Tomcat服务器的CORS机制，允许跨域请求，详细说明了CORS的原理和在Tomcat中的配置步骤，包括CORS过滤器的使用和参数配置，以及通过Nginx进行反向代理的方法。


本文还有配套的精品资源，点击获取
menu-r.4af5f7ec.gif

Logo
天工造物局

北京人形旗下天工造物具身智能开源社区，聚焦具身天工与慧思开物两大平台

更多推荐

deck.gl TripsLayer 出租车轨迹动画示例实战：从示例运行到着色器原理

TripsLayer 是 deck.gl 中用于渲染**随时间流动的轨迹动画**（如出租车行程、物流路径、迁徙路线）的核心图层。本文以仓库中的最小独立示例 [examples/website/trips](https://link.gitcode.com/i/1442af8f442f4cff39ff546e050fceb5) 为骨架，带你完成从安装依赖、启动应用、理解曼哈顿出租车数据格式，到深入

avatar 天工造物局

Foundry Anvil 中 eth_simulateV1 的 Blob 交易与 Blob Gas 字段规范化：原理、实现与测试验证

本篇技术指南以 [anvil-simulate-blob-transactions.md](https://link.gitcode.com/i/3d2ebe227262de169335eb290af80da8) 这条 changelog 条目为起点，深入剖析 Foundry Anvil 对 `eth_simulateV1` RPC 返回结果中 blob（EIP-4844）交易与 blob gas

avatar 天工造物局

LMCache CLI 实战：用 `lmcache kvcache clear` 管理运行中服务的 KV Cache 状态

本文是一份针对 LMCache 官方 CLI 命令 `lmcache kvcache` 的完整技术指南。该命令用于在**运行中的 LMCache 服务（MP HTTP server）**上管理 KV cache 状态，当前提供 `clear` 子命令，用于清空 L1（CPU 内存）层中缓存的全部 KV 数据。读完本文，你将掌握该命令的完整参数体系、退出码语义、终端/JSON/静默三种输出模式，并能

avatar 天工造物局