碼上快樂

相關內容    簡體    繁體

tomcat跨域請求過濾器CorsFilter使用的預檢preFlight及其他過濾器

本文轉載自   查看原文   2020-06-07 11:15   679    tomcat

前言

　　之前我很膚淺的以為為了實現某種請求過濾功能（比如圖片轉換、文件上傳、安全認證等），都需要自己去實現javax.servlet.Filter。之后在web.xml中配置即可。

　　但事實上，Tomcat已經提供了部分相關的過濾器（本文只介紹常用的7個過濾器），只需要簡單配置就可以使用。最近通過系統學習Tomcat架構之后，結合部分源碼記錄總結最常用的幾種過濾器。

　　參考資料《Tomcat架構解析》（有需要PFD電子書的朋友可以評論或者私信），Tomcat官方Filter配置（Tomcat 8為例）

 

 

 

 

一、跨域過濾器CorsFilter

一. 為什么要發預檢請求

我們都知道瀏覽器的同源策略，就是出於安全考慮，瀏覽器會限制從腳本發起的跨域HTTP請求，像XMLHttpRequest和Fetch都遵循同源策略。
瀏覽器限制跨域請求一般有兩種方式：

  1. 瀏覽器限制發起跨域請求
  2. 跨域請求可以正常發起，但是返回的結果被瀏覽器攔截了

一般瀏覽器都是第二種方式限制跨域請求，那就是說請求已到達服務器，並有可能對數據庫里的數據進行了操作，但是返回的結果被瀏覽器攔截了，那么我們就獲取不到返回結果，這是一次失敗的請求，但是可能對數據庫里的數據產生了影響。

為了防止這種情況的發生，規范要求，對這種可能對服務器數據產生副作用的HTTP請求方法，瀏覽器必須先使用OPTIONS方法發起一個預檢請求，從而獲知服務器是否允許該跨域請求：如果允許，就發送帶數據的真實請求；如果不允許，則阻止發送帶數據的真實請求。

二. 什么時候發預檢請求

HTTP請求包括： 簡單請求 和 需預檢的請求

1. 簡單請求

簡單請求不會觸發CORS預檢請求，“簡屬於
單請求”術語並不屬於Fetch(其中定義了CORS)規范。
若滿足所有下述條件，則該請求可視為“簡單請求”：

  • 使用下列方法之一：
    • GET
    • HEAD
    • POST
      • Content-Type: (僅當POST方法的Content-Type值等於下列之一才算做簡單需求)
        • text/plain
        • multipart/form-data
        • application/x-www-form-urlencoded

注意: WebKit Nightly 和 Safari Technology Preview 為Accept
, Accept-Language
, 和 Content-Language
 首部字段的值添加了額外的限制。如果這些首部字段的值是“非標准”的，WebKit/Safari 就不會將這些請求視為“簡單請求”。WebKit/Safari 並沒有在文檔中列出哪些值是“非標准”的，不過我們可以在這里找到相關討論：Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS, and Switch to a blacklist model for restricted Accept headers in simple CORS requests。其它瀏覽器並不支持這些額外的限制，因為它們不屬於規范的一部分。

2.需預檢的請求

“需預檢的請求”要求必須首先使用OPTIONS方法發起一個預檢請求到服務區，以獲知服務器是否允許該實際請求。“預檢請求”的使用，可以避免跨域請求對服務器的用戶數據產生未預期的影響。

當請求滿足下述任一條件時，即應首先發送預檢請求：

  • 使用了下面任一 HTTP 方法：
    • PUT
    • DELETE
    • CONNECT
    • OPTIONS
    • TRACE
    • PATCH
  • 人為設置了對 CORS 安全的首部字段集合之外的其他首部字段。該集合為：
    • Accept
    • Accept-Language
    • Content-Language
    • Content-Type
    • DPR
    • Downlink
    • Save-Data
    • Viewport-Width
    • Width
    • Content-Type的值不屬於下列之一:
      • application/x-www-form-urlencoded
      • multipart/form-data
      • text/plain

如下是一個需要執行預檢請求的HTTP請求：

var invocation = new XMLHttpRequest(); var url = 'http://bar.other/resources/post-here/'; var body = '<?xml version="1.0"?><person><name>Arun</name></person>'; function callOtherDomain(){ if(invocation) { invocation.open('POST', url, true); invocation.setRequestHeader('X-PRODUCT', 'H5'); invocation.setRequestHeader('Content-Type', 'application/xml'); invocation.onreadystatechange = handler; invocation.send(body); } } ......

上面的代碼使用POST請求發送一個XML文檔，該請求包含了一個自定義的首部字段（X-PRODUCT:H5）。另外，該請求的Content-Type為application/xml。因此，該請求需要首先發起“預檢請求”。

如果是一個簡單請求，那就直接發起請求，只需在請求中加入Origin字段表明自己來源，在響應中檢查
Access-Control-Allow-Origin，如果不符合要求就報錯，不需要再單獨詢問了。服務器響應字段中還有一個Access-Control-Max-Age，它表明了這個詢問結果的有效期，后面瀏覽器在有效期內也可以不必再次詢問。

在OPTIONS請求里新增了幾個字段：

  • Origin：發起請求原來的域
  • Access-Control-Request-Method：將要發起的跨域請求方式（GET/PUT/POST/DELETE/······）
  • Access-Control-Request-Headers：將要發起的跨域請求中包含的請求頭字段

服務器在響應字段中來表明是否允許這個跨域請求，瀏覽器收到后檢查如果不符合要求，就拒絕后面的請求

  • Access-Control-Allow-Origin：允許哪些域來訪問（*表示允許所有域的請求）
  • Access-Control-Allow-Methods：允許哪些請求方式
  • Access-Control-Allow-Headers：允許哪些請求頭字段
  • Access-Control-Allow-Credentials：是否允許攜帶Cookie

而org.apcache.catalina.filters.CorsFilter是跨域資源共享規范的一個實現，常常用於前后端分離，靜態資源與后端分離等情況。它主要在HttpServletResponse中增加Access-Control-*頭，同時保護HTTP響應避免拆分，如果請求無效或者禁止訪問，則返回403響應碼。

配置示例

復制代碼 
<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-name>cors.allowed.headers</param-name>
    <param-value>Content-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers</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>
復制代碼

 

參數說明

　　1、cors.allowed.origins

　　　　允許訪問的跨域資源列表，"*"表示允許訪問來自任何域的資源，多個域用逗號分隔，默認為"*"

　　2、cors.allowed.methods

　　　　可以用於訪問資源的HTTP方法列表，","分隔，用於跨域請求。這些方法將出現在Prefligh（預檢請求）響應頭Access-Control-Allow-Methods的一部分，t默認為"GET, POST, HEAD, OPTIONS"

　　3、cors.allowed.headers

　　　　構造請求時可以使用的請求頭，以","分隔，這些方法將出現在Prefligh（預檢請求）響應頭Access-Control-Allow-Headers的一部分，默認為Origin, Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers

　　4、cors.exposed.headers

　　　　瀏覽器允許訪問的頭部信息列表，","分隔。這些方法將出現在Prefligh（預檢請求）響應頭Access-Control-Allow-Headers的一部分，默認為空。

　　5、cors.preflight.maxage

　　　　瀏覽器允許緩存的Preflght請求結果的時間，單位為秒。如果為負數，則表示CorsFilter不會添加頭到Preflight響應，這些方法將出現在Prefligh（預檢請求）響應頭Access-Control-Max-Age的一部分，默認為1800.

　　6、cors.support.credentials

　　　　表示資源是否支持用戶證書，這些方法將出現在Prefligh（預檢請求）響應頭Access-Control-Allow-Credentials的一部分，默認為true

　　7、cors.request.decorate

　　　　Cors規范屬性是否已經添加到HttpServletRequest，默認為true。CorsFiter會為HttpServletRequest添加請求相關信息，cors.request.decorate配置為true，那么以下屬性將會被添加

　　　　1）cors.isCorsRequest: 用於請求是否為Cors請求。

　　　　2）cors.request.origin: 源URL，請求源自的頁面URL。

　　　　3）cors.request.type: Cors的請求類型，如下：

　　　　　　SIMPLE: 非Preflight請求為先導的請求。

　　　　　　ACTUAL: 以Preflight請求為先導的請求。

　　　　　　PRE_FLIGHT: Preflight請求

　　　　　　NOT_CORS: 正常同域請求

　　　　　　INVALID_CORS: 無效的域請求

　　　　4）cors.request.headers: 作為Preflight請求Access-Control-Request-Header頭發送的請求頭信息。

 

preFlight踩過的坑

這兩天在使用NodeJS Express搭建REST服務器時遇到一個很典型的AJAX跨域包含自定義請求頭問題（用於身份驗證），在花了大半天時間排查問題后發現自己對CORS真正的理解還很不夠，尤其是pre-flight。

需求描述

服務端使用NodeJS Express搭建包含JWT身份驗證的REST Full API， 客戶端在獲取到JWT信息之后的每次API請求頭中都附帶上JWT信息，完成身份驗證后才能執行API操作，否則返回401錯誤。

代碼

服務器端(CORS核心部分):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
------ App -----
...
// Enable CORS from client-side
app.use(function (req, res, next) {
 res.header("Access-Control-Allow-Origin", "*");
 res.header("Access-Control-Allow-Methods", "PUT, GET, POST, DELETE, OPTIONS");
 res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept, Authorization, Access-Control-Allow-Credentials");
 res.header("Access-Control-Allow-Credentials", "true");
 next();
});

//parse application/json and look for raw text 
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));
app.use(bodyParser.text());
app.use(bodyParser.json({ type: 'application/json' }));

// Routes configuration
apiRoutes(app);

app.listen(port);

------- User -----
//==========================
// User Routes
//==========================
apiRoutes.use('/user', passport.authenticate('jwt', {session: false }), userRoutes);
userRoutes.get('/', user.getUsers);
userRoutes.get('/:id', user.getUser);
userRoutes.post('/', user.postUser);
userRoutes.put('/:id', user.updateUser);
userRoutes.delete('/:id', user.deleteUser);

上面的代碼看起來還是那么多清晰，在PostMan 測試中附帶jwt也是沒有任何的問題，成功返回。
image

接下來是客戶端(jquery ajax):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
------- Core --------
function BaseManager(auth) {
 this.baseApiUrl = 'http://localhost:8080/api/';
 this.auth = auth;
}
BaseManager.prototype.get = function (url, successCallback, errorCallback) {
 this.ajax(url, {}, 'get', successCallback, errorCallback);
}
BaseManager.prototype.ajax = function (url, data, type, successCallback, errorCallback) {
 let that = this;
 $.ajax({
 url: url,
 method: type,
 data: data,
 beforeSend: function (req) {
 req.setRequestHeader('Authorization', that.auth.authorizationToken);
 }
 })
 .done(successCallback)
 .fail(errorCallback);
}
----------- User -------
User.prototype.getUserById = function (id, successCallback, errorCallback) {
 let url = this.baseApiUrl + '/user/' + id;
 this.get(url, successCallback, errorCallback);
}

永遠的401

然后， 問題出現了，盡管參數是如何的對，Chrome console下總是返回讓人咬牙切齒的大紅色401，甚至斷點都沒有進入到passport的Jwt middleware下。
image

無數次的嘗試，先是懷疑客戶端ajax調用沒對，甚至搬用最原生的ajax方法， 也懷疑過是服務端Jwt passport沒寫對，最后比較http請求頭的時候發現了一些問題。

使用Post man在node服務器端得到的request是這樣的：

image

通過瀏覽器ajax請求是這樣的：
image

有人給我把請求頭信息更改了！Authorization不見了，甚至連req.method都變成了OPTIONS，而不是GET。

罪魁禍首—預檢(Pre-flight)

百思不得其解，Google相關關鍵詞后，pre-flight浮出水面，到了這步，突然想起阮一峰的《跨域資源共享 CORS 詳解》，當時只是略讀，大概了解CORS中有兩種請求：簡單請求和非簡單請求。於是又翻出來看了下，此時的情況正是屬於非簡單請求，會發送兩次的請求，第一次就是preflight，用於請求驗證, 第二次才是用戶真正需要發送的請求。

對於Pre-flight權威的解讀： mozilla.org

回到代碼中，不巧，每次服務端捕捉到的就是這個preflight請求，然后做next，其中就包括Jwt 中間件，而因為請求頭中沒有Authorization這個header，Jwt就返回了401，而這個過程是在passport的JWT中自動檢測的，自己寫的JWT驗證部分甚至都沒有執行到！

解決辦法

看了express cors源碼后，其實把請求類型OPTIONS做個簡單的過濾就好啦！！！

1
2
3
4
5
6
7
8
9
10
11
12
13
 
// Enable CORS from client-side
app.use(function (req, res, next) {
 res.header("Access-Control-Allow-Origin", "*");
 res.header("Access-Control-Allow-Methods", "PUT, GET, POST, DELETE, OPTIONS");
 res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept, Authorization, Access-Control-Allow-Credentials");
 res.header("Access-Control-Allow-Credentials", "true");
 if (req.method == "OPTIONS") {
 res.send(200);
 }
 else {
 next();
 }
});

總結：

又想了一下為什么之前的項目一直沒有這個問題，其實是因為很多框架以及幫我們實現好了，比如說.NET中的WebAPI, 在做驗證的時候我們都不用去考慮需要捕捉pre-flight請求，而在express中，甚至如果我當初直接使用三方庫express cors 也可以避免，但是幸運的是，因為這種偶然，我們更有機會看得更清楚這些請求的后面到底是什么。

看似簡單的問題，卻包括了很多需要自己去了解的東西，尤其是http各種請求頭的含義，比如Content-type, Accept, 以及對應ajax應該傳遞的參數，最后，當然還有 Pre-flight!

　

二、CSRF保護過濾器CsrfPreventionFilter

　　org.apcache.catalina.filters.CsrfPreventionFilter為Web應用提供了基本的CSRF保護。返回的客戶端的所有鏈接均通過HttpServletResponse.encodeRedirectURL(String)與HttpServletResponse.encodeURL(String)進行編碼，該過濾器生成一個隨機數並存儲到會話session中進行對比，URL使用該隨機數進行編碼。當接收到下一個請求時，請求中隨機數與會話中的進行對比，只有兩者相同時，請求才會被允許。

配置示例

復制代碼 
<filter>
        <filter-name>CsrfPreventionFilter</filter-name>
        <filter-class>org.apache.catalina.filters.CsrfPreventionFilter</filter-class>
        <init-param>
            <param-name>denyStatus</param-name>
            <param-value>403</param-value>
        </init-param>
        <init-param>
            <param-name>entryPoints</param-name>
            <param-value>/html,/html/list</param-value>
        </init-param>
        <init-param>
            <param-name>nonceCacheSize</param-name>
            <param-value>5</param-value>
        </init-param>
    </filter>
    <filter-mapping>
        <filter-name>CsrfPreventionFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
復制代碼

 

參數說明

　　1、denyStatus：HTTP響應嗎，用於駁回拒絕請求，默認為403

　　2、entryPoints：以","為分隔的URL列表，這些列表將不會進行隨機數檢測（主要用於通過導航離開受保護應用，之后再返回）　

 if ("GET".equals(req.getMethod()) && this.entryPoints.contains(this.getRequestedPath(req))) {
                skipNonceCheck = true;
 }

　　3、nonceCacheSize：隨機數緩存大小。先前發布的隨機數被緩存到一個LRU緩存中以支持並發請求，有限的用於瀏覽器刷新等行為（可能導致隨機數不是當前的），默認為5

復制代碼 
private int nonceCacheSize = 5;
....
if (nonceCache == null) {
  　　nonceCache = new CsrfPreventionFilter.LruCache(this.nonceCacheSize);
      if (session == null) {
           session = req.getSession(true);
     　　}

    session.setAttribute("org.apache.catalina.filters.CSRF_NONCE", nonceCache);
}
復制代碼

　　4、randomClass：用於生成隨機數的類，必須是java.util.Random實例，如不設置默認為java.security.SecureRandom

 

三、防止參數丟失過濾器FailedRequestFilter

　　org.apcache.catalina.filters.FailedRequestFilter用於觸發請求的參數解析，當參數解析失敗時，將會拒絕請求，該Filter用於確保客戶端提交的參數信息不發生丟失。該過濾器的原理是：先調用ServletRequest.getParameter（首次調用會觸發Tomcat服務器的請求參數解析，如果參數解析失敗，將結果放到請求屬性org.apache.catalina.parameter_parse_failed中），之后判斷屬性org.apache.catalina.parameter_parse_failed的值，如果不為空則直接返回400。

　　為了能正確解析參數，需要該Filter之前設置字符集編碼過濾器SetCharacterEncodingFilter。此外，該過濾器是不支持r初始化參數的

// 判斷是否為有效的請求：org.apache.catalina.parameter_parse_failed為null
private boolean isGoodRequest(ServletRequest request) {
        request.getParameter("none");
        return request.getAttribute("org.apache.catalina.parameter_parse_failed") == null;
    }

 

四、獲取客戶端IP過濾器RemoteAddrFilter

　　org.apcache.catalina.filters.RemoteAddrFiler允許比較提交的客戶端IP地址（通過ServletRequest.getRemoteAddr獲取）是否符合指定正則表達式。

配置示例

復制代碼 
    <filter>
      <filter-name>Remote Address Filter</filter-name>
      <filter-class>org.apache.catalina.filters.RemoteAddrFilter</filter-class>
      <init-param>
        <param-name>allow</param-name>
        <param-value>127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1</param-value>
      </init-param>
    </filter>
    <filter-mapping>
      <filter-name>Remote Address Filter</filter-name>
      <url-pattern>/*</url-pattern>
    </filter-mapping>
復制代碼

參數說明

　　1、allow：指定允許訪問的客戶端IP地址

　　2、deny：拒絕訪問的客戶端地址

　　3、denyStatus：拒絕請求時返回的HTTP響應嗎。

 

五、獲取客戶端Host過濾器RemoteHostFilter

　　org.apcache.catalina.filters.RemoteHostFiler允許比較提交請求的客戶端主機名是否符合指定的正則表達式，以確定是否允許繼續處理請求。參數同RemoteAddrFilter

 

六、獲取原始客戶端IP過濾器RemoteIpFilter

　   當客戶端通過HTTP代理或者負載均衡訪問服務器時，對於服務器來說，請求直接源自前置的代理服務器，此時獲取到的遠程IP實際為代理服務器的IP地址。

      這時候如何獲得原始的客戶端的IP地址呢？

      HTTP協議通過X-Forwarded-For頭信息記錄了資客戶端到應用服務器前置代理的IP地址，RemoteIpFilter通過解析該請求頭，將請求中的IP地址與主機名替換為客戶端真實的IP地址和主機信息，此外還可以通過X-Forwardred-Proto請求頭替換當前的協議名稱http/https、服務器端口及request.secure。

      X-Forwarded-For的格式如下：

      X-Forwarded-For:  client, proxy1, proxy2

      最左側client為最原始的客戶端IP，如上示例中客戶端經過了proxy1、proxy2、proxy3三級代理（最后一層proxy3不顯示，通過ServletRquest.getRemoteAddr獲取）。在負載均衡的情況下，RemoteAddrFilter和RemoteHostFilter需要與該過濾器配合使用，否則無法正確限制訪問客戶端。

　　通常我們獲取X-Forwarded-For使用如下Java代碼：

復制代碼 
 public static String getIp(HttpServletRequest request) {
        String requestAddr = request.getHeader("x-forwarded-for");
        if (requestAddr == null || requestAddr.length() == 0 || "unknown".equalsIgnoreCase(requestAddr)) {
            requestAddr = request.getHeader("Proxy-Client-IP");
        }

        if (requestAddr == null || requestAddr.length() == 0 || "unknown".equalsIgnoreCase(requestAddr)) {
            requestAddr = request.getHeader("WL-Proxy-Client-IP");
        }

        if (requestAddr == null || requestAddr.length() == 0 || "unknown".equalsIgnoreCase(requestAddr)) {
            requestAddr = request.getRemoteAddr();
        }

        return requestAddr;
    }
復制代碼

 

 

 

配置示例

　　1）基本處理X-Forwarded-For頭的配置

復制代碼 
  <filter>
        <filter-name>RemoteIpFilter</filter-name>
        <filter-class>org.apache.catalina.filters.RemoteIpFilter</filter-class>
      </filter>

      <filter-mapping>
        <filter-name>RemoteIpFilter</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
      </filter-mapping>
復制代碼

　　2）處理X-Forwarded-For與x-forwarded-proto頭部的配置

復制代碼 
  <filter>
        <filter-name>RemoteIpFilter</filter-name>
        <filter-class>org.apache.catalina.filters.RemoteIpFilter</filter-class>
        <init-param>
          <param-name>protocolHeader</param-name>
          <param-value>x-forwarded-proto</param-value>
        </init-param>
      </filter>

      <filter-mapping>
        <filter-name>RemoteIpFilter</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
      </filter-mapping>
復制代碼

　　3）使用內部代理的高級配置

復制代碼 
 <filter>
       <filter-name>RemoteIpFilter</filter-name>
       <filter-class>org.apache.catalina.filters.RemoteIpFilter</filter-class>
       <init-param>
         <param-name>allowedInternalProxies</param-name>
         <param-value>192\.168\.0\.10|192\.168\.0\.11</param-value>
       </init-param>
       <init-param>
         <param-name>remoteIpHeader</param-name>
         <param-value>x-forwarded-for</param-value>
       </init-param>
       <init-param>
         <param-name>remoteIpProxiesHeader</param-name>
         <param-value>x-forwarded-by</param-value>
       </init-param>
       <init-param>
         <param-name>protocolHeader</param-name>
         <param-value>x-forwarded-proto</param-value>
       </init-param>
     </filter>
復制代碼

　　4）使用可信任代理高級配置

復制代碼 
<filter>
       <filter-name>RemoteIpFilter</filter-name>
       <filter-class>org.apache.catalina.filters.RemoteIpFilter</filter-class>
       <init-param>
         <param-name>allowedInternalProxies</param-name>
         <param-value>192\.168\.0\.10|192\.168\.0\.11</param-value>
       </init-param>
       <init-param>
         <param-name>remoteIpHeader</param-name>
         <param-value>x-forwarded-for</param-value>
       </init-param>
       <init-param>
         <param-name>remoteIpProxiesHeader</param-name>
         <param-value>x-forwarded-by</param-value>
       </init-param>
       <init-param>
         <param-name>trustedProxies</param-name>
         <param-value>proxy1|proxy2</param-value>
       </init-param>
     </filter>
復制代碼

 

七、字符集編碼過濾器SetCharacterEncodingFilter

　　提供了一種設置字符集編碼的方式，通常情況下默認ISO-8859-1編碼，但實際生產環境推薦使用UTF-8編碼，而請求中的編碼可以在未指定編碼時使用，也可以強制覆蓋。

配置示例

復制代碼 
<filter>
        <filter-name>SetCharacterEncodingFilter</filter-name>
        <filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
        <init-param>
            <param-name>encoding</param-name>
            <param-value>UTF-8</param-value>
        </init-param>
        <init-param>
            <param-name>ignore</param-name>
            <param-value>false</param-value>
        </init-param>
    </filter>
    <filter-mapping>
        <filter-name>SetCharacterEncodingFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
復制代碼

參數說明

　　1、encoding：指定的字符集編碼　　

　　2、ignore：表示是否忽略客戶端請求設置的字符集編碼，如果為true那么都會將請求字符集編碼覆蓋，如果為false，請求沒有指定字符集編碼時設置。默認為false

 

轉自：https://www.jianshu.com/p/b55086cbd9af

https://www.cnblogs.com/jian0110/p/10512188.html

https://troyyang.com/2017/06/06/Express_Cors_Preflight_Request/


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 處理跨域Options預檢請求 servlet 過濾器實現 請求轉發（跳轉）；跨域轉發請求；tomcat 環境下。 shiro 和 跨域過濾器沖突 GateWay全局過濾器（Global Filters）配置及跨域請求 跨站點請求偽造 - SpringBoot配置CSRF過濾器 Http跨域時候預檢沒通過的幾種原因 跨域問題，通過gateway網關配置filter過濾器。實現跨域問題的解決 淺析SpringSecurity對跨域非簡單請求的Prefight預檢請求的處理：requestMatchers(CorsUtils::isPreFlightRequest).permitAll()、及簡單請求與非簡單請求的理解 如何解決跨域問題，以及跨域預檢未通過問題 filter過濾器的使用
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM