入職多年，面對生產環境，盡管都是小心翼翼，慎之又慎，還是難免捅出簍子，輕則滿頭大汗，面紅耳赤，重則系統停擺，損失資金，每一個生產事故的背后，都是寶貴的經驗和教訓，都是專案成員的血淚史，為了更好地防范和遏制今后的各類事故，特開此專題，長期更新和記錄大大小小的各類事故，有些是親身經歷，有些是經人耳傳口授，但無一例外都是真實案例，
注意：為了避免不必要的麻煩和商密問題，文中提到的特定名稱都將是化名、代稱，
0x00 大綱
目錄- 0x00 大綱
- 0x01 事故背景
- 0x02 事故分析
- 0x03 事故原因
- 0x04 事故復盤
- 0x05 事故影響
0x01 事故背景
2021年11月26日01時10分，P公司正在進行某業務系統的生產環境部署操作，但其實早在00時30分的時候，他們已經完成過一次部署了，但是奇怪的是無論如何都通不過驗證，無奈只好推倒重來，如此反復了有若干次，為何反復嘗試，卻不嘗試去尋找問題呢？問題就在于該系統同一份代碼在開發環境和 UAT 環境均一切正常，唯獨部署到生產環境上面就不行，這是一個前后端分離的業務系統，前端與后端介面基于 JWT 而不是傳統 Session 進行鑒權認證，故障的現象也很簡單，就是無法登錄——準確的說，是登錄后不能維持登錄狀態，一訪問其他需要鑒權的資源立馬又被重定向到登錄頁面，2020年10月25日02時30分，在運維人員多次嘗試無果，開發人員排查代碼也未發現問題后，P公司不得不直呼見鬼，那么真相究竟是什么呢？
0x02 事故分析
在 RFC 7519 規范中對于 JWT 是這樣描述的：
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code(MAC) and/or encrypted.
JWT (JSON Web Token) 是一種緊湊、URL 安全的表示方式，用于表達要在兩個參與方之間傳輸的安全宣告，JWT 中的宣告被編碼為 JSON 物件，作為 JSON Web Signature (JWS) 結構的有效載荷或 JSON Web Encryption (JWE) 結構的明文，使得宣告可以使用訊息認證碼 (MAC) 進行數字簽名或完整性保護和/或加密，
說人話呢意思就是 JWT 是一種安全令牌的標準化實作，用于參與雙方之間的可信互動認證，既然不好定位是環境還是代碼的問題，不妨先捋一捋 JWT 鑒權認證的程序，看看問題可能發生在哪一步：
- 從故障現象來看，步驟①出問題的可能性基本被排除，從前端請求和后端日志來看賬號和密碼的驗證程序已經正確完成；
- 那么步驟②有沒有可能出問題呢？當時也是懷疑過的，但是使用瀏覽器的 F12 開發者工具，看到 login 的網路請求回應中已經將后端生成的 JWT 回傳來了；
- 莫非是步驟③沒有將 JWT 正確攜帶，導致后續驗證不通過？但是查看登陸后，對其他介面的請求，里面確實已經攜帶了步驟②中提供的 JWT，而且數值也一致；
- 驗證JWT的代碼邏輯會不會有問題呢？可能性不大，因為在測驗環境和 UAT 環境已經反復驗證過，
那么問題還是出在步驟③攜帶 JWT 這一步，前面分析過前端發起請求時，已經攜帶了 JWT，那么有沒有可能是后端沒收到或者收到的值不正確呢？很可惜，后端收到 JWT 后沒有列印相關的日志……只有簡單的提示驗證失敗的資訊，但其實到這里，已經可以懷疑是環境的問題了，因為同樣的代碼只在生產環境出錯，
隨機抽取一個運維小伙子，讓他說說生產的系統結構，從他口中得知，生產上除了為了部署多個節點，使用了 Nginx 作為負載均衡和反向代理外，其他地方沒有區別，憑借往常的經驗呢，P公司的員工們首先呢就沒有懷疑過反代和負載會影響這個業務功能，但是我們的理性分析又提示我們問題很有可能出在這里，
不妨找個機器驗證一下，安裝和生產環境相同版本的 Nginx，然后配置一下反代和負載，對了，這回啊，在后端把列印 JWT 的Debug日志加上，然后果不出所料，前端雖然在請求頭中攜帶了 JWT，但是到了后端，卻顯示沒有這個資訊，這個頭，它丟到哪里去了呢？
0x03 事故原因
前端在步驟③請求頭中攜帶的 JWT 如下，HTTP_HEADER_NAME 為 “JWT_TOKEN”，HTTP_HEADER_VALUE 為 JWT 的值：
JWT_TOKEN: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjpbb2x0...
在后端日志中，除了 JWT_TOKEN 以外，其他的頭部資訊都正常傳遞，我們注意到，它的 HTTP_HEADER_NAME 包含了下劃線，這是它與眾不同的地方，難道是被 Nginx 過濾了？
在 Nginx 的官方檔案里，有這么一段話：
Missing (disappearing) HTTP Headers
If you do not explicitly set underscores_in_headers on;, NGINX will silently drop HTTP headers with underscores (which are perfectly valid according to the HTTP standard). This is done in order to prevent ambiguities when mapping headers to CGI variables as both dashes and underscores are mapped to underscores during that process.
消失的 HTTP Headers
如果你沒有顯式設定 underscores_in_headers on;，NGINX 會靜悄悄地干掉帶有下劃線的 HTTP 請求頭（雖然它們符合 HTTP 規范，毀滅你與你何干……），這樣做是為了防止在將請求頭映射到 CGI 變數時出現歧義，因為在此程序中，短劃線和下劃線都映射到下劃線，
在 ngx_http_parse.c 中，這個開關是這樣處理的：
/* header name */
case sw_name:
c = lowcase[ch];
if (c) {
hash = ngx_hash(hash, c);
r->lowcase_header[i++] = c;
i &= (NGX_HTTP_LC_HEADER_LEN - 1);
break;
}
if (ch == '_') {
if (allow_underscores) {
hash = ngx_hash(hash, ch);
r->lowcase_header[i++] = ch;
i &= (NGX_HTTP_LC_HEADER_LEN - 1);
} else {
r->invalid_header = 1;
}
break;
}
// ……（太長只截取關鍵部分）
break;
如果沒有開啟underscores_in_headers開關，對應變數allow_underscores，則默認情況下，帶有下劃線的 HTTP_HEADER 會被標記為 INVALID_HEADER.而標記為 INVALID_HEADER 的資訊默認情況下，會被忽略掉，為什么說默認呢？因為這個行為同時還受到另一個開關ignore_invalid_headers控制，如果它被開啟，那么帶有下劃線的 HTTP_HEADER 就真的神秘消失了，
關于 underscores_in_headers 選項：
Syntax: underscores_in_headers on | off;
Default: underscores_in_headers off;
Context: http, server
Enables or disables the use of underscores in client request header fields. When the use of underscores is disabled, request header fields whose names contain underscores are marked as invalid and become subject to the ignore_invalid_headers directive.
關于 ignore_invalid_headers 選項：
Syntax: ignore_invalid_headers on | off;
Default: ignore_invalid_headers on;
Context: http, server
Controls whether header fields with invalid names should be ignored. Valid names are composed of English letters, digits, hyphens, and possibly underscores (as controlled by the underscores_in_headers directive).
可以看到underscores_in_headers選項默認情況下是關閉的，而ignore_invalid_headers選項默認情況下是開啟的，這也就導致了我們 JWT_TOKEN 的神秘失蹤，至此問題已經定位完畢，
0x04 事故復盤
這次可以說是純純的意外，但是這個意外本可以發現的更早：
- 再窮也好，至少也要申請一個與生產環境相同/相仿的復刻環境，
- 統一且規范的命名，或許可以避免很多不必要的麻煩，
- 所謂
Debug日志就是，沒事的時候，你看到它嫌它煩；出事的時候，你煩看不到它…… - 排查問題時，還是大意了，沒有去看 Nginx 的日志，因為通過原始碼可以發現 INVALID_HEADER 默認情況下是會觸發 ERROR 日志的：
if (rc == NGX_OK) { r->request_length += r->header_in->pos - r->header_name_start; if (r->invalid_header && cscf->ignore_invalid_headers) { /* there was error while a header line parsing */ ngx_log_error(NGX_LOG_INFO, c->log, 0, "client sent invalid header line: \"%*s\"", r->header_end - r->header_name_start, r->header_name_start); continue; } // ……（太長只截取關鍵部分） }
0x05 事故影響
使P公司新業務系統上線時間延長了3小時，相關人員連夜跟老板申請服務器經費，（知道了，下次還是不批），
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/550361.html
標籤：其他
上一篇：【vue3-element-admin】Husky + Lint-staged + Commitlint + Commitizen + cz-git 配置 Git 提交規范