Hi, I’m Hsien-Te Hsieh 🧑🏻‍💻

前言 最近工作上在研究 API 認證方案，整理了一個 Kong HMAC Demo 來驗證 HMAC-SHA256 作為 Kong API Gateway 認證機制的可行性。趁還沒忘掉，記錄一下核心觀念與適用場景。 什麼是 HMAC HMAC（Hash-based Message Authentication Code）是一種利用雜湊函數（如 SHA-256）與共享金鑰（shared secret）產生訊息鑑別碼（MAC）的機制。 實際在 HTTP 請求中，client 會選取特定 header（例如 Date），以金鑰對其進行 HMAC 運算，產生 signature，再附在 Authorization header 中送出。 Authorization: hmac username="demo-user", algorithm="hmac-sha256", headers="date", signature="<base64-encoded-signature>" 為什麼 HMAC 可以作為身份驗證 HMAC 能作為身份驗證的核心原因在於：只有持有正確金鑰的人，才能產生出合法的 signature。 驗證流程如下： Client 計算簽章： Client 使用共享金鑰對指定 headers 計算 HMAC 簽章，附在請求中送出。 Server 重算比對： Server（這裡是 Kong）收到請求後，根據 username 找到對應的 consumer 及其 secret，對相同的 headers 重新計算一次 HMAC。 比對結果： 若兩端計算出的 signature 一致，代表請求方持有正確金鑰，身份即可確認。 防重放攻擊： Kong 的 HMAC plugin 要求簽章必須包含 Date header，並設定允許的時間偏移（clock skew）。若請求的時間戳記超出允許範圍（預設 ±300 秒），Kong 會直接拒絕請求，防止攻擊者截取請求後重放。 ...

前言 這個部落格跑了一段時間，但我一直沒有好好整理它是怎麼運作的。趁現在記錄一下：本地怎麼新增文章、推上 GitHub 後又發生了什麼事，讓網站自動更新。 專案結構 整個 GitHub repository（arieshsieh0402.github.io）的結構如下： arieshsieh0402.github.io/ ← git repo 根目錄 ├── .github/ │ └── workflows/ │ └── hugo.yaml ← GitHub Actions 部署設定 ├── AriesHsieh/ ← Hugo 專案目錄 │ ├── archetypes/ │ │ └── posts.md ← 新文章的預設模板 │ ├── content/ │ │ └── posts/ ← 所有文章放這裡 │ ├── themes/ │ │ └── PaperMod/ ← 使用的 Hugo 主題 │ ├── public/ ← hugo build 產生的靜態檔案（不進 git） │ └── hugo.yaml ← Hugo 網站設定 Hugo 專案本身放在 repo 根目錄下的 AriesHsieh/ 子目錄，而非 repo 根目錄。這個結構在 GitHub Actions 設定中需要特別注意 working directory。 ...

Kong 與 Nginx 設定關係筆記 工作上遇到一些狀況，需要處理 HTTPS 加解密演算法，剛好趁這個機會記錄一下 Kong 跟 Nginx 的關係。 這邊以 SSL Ciphers 為例，整理 Kong 設定如何流向至 Nginx 實際生效的過程。 概念架構 Kong 的設定與 Nginx 的設定之間存在著三層結構： 層級 檔案位置 用途 源頭 kong.conf Kong 的主設定檔，定義所有運行參數 入口 nginx.conf Nginx 的起點，僅做全域/事件設定，在 http {} 內 include 真正的設定檔 生效 nginx-kong.conf 實際生效的設定，包含 ssl_ciphers、ssl_protocols、各個 listen 等 TLS/Server 設定 簡單來說：kong.conf 是來源、nginx.conf 是入口、nginx-kong.conf 是實際生效結果。 設定流向 - 以 SSL Ciphers 為例 Step 1: 源設定 在 kong.conf 設定 ssl_cipher_suite 和 ssl_ciphers： ssl_cipher_suite = custom ssl_ciphers = ECDHE-RSA-AES256-GCM-SHA384:... Step 2: Kong 翻譯 當你執行 kong start 或 kong restart 時，Kong 會根據 kong.conf 生成 Nginx 的實際設定。 ...

看到一篇文章寫的不錯，紀錄留存一下，並且簡單的重點整理。 本文僅做紀錄與整理，觀點本身皆來自原文作者。 原文：https://www.facebook.com/100063744608911/posts/1526846902783449/?mibextid=wwXIfr&rdid=ABv4HxePsdb0LmOe Agent 開發的三個階段演變 第一階段：工具連接期 (Function Calling / MCP) 作法：利用 LLM 的 API 與 Function Calling 能力，將 AI 與後端系統串接。後來演變成標準化的 MCP (Model Context Protocol)。 痛點：技術門檻過高，能獨立完成的人很少。 第二階段：多代理協作期 (A2A / Multi-Agent) 作法：類似 Google 提出的 Agent to Agent，讓多個 AI 各司其職。 痛點：類似「微服務」亂象，過度設計 (Over-engineering)。管理多個 Agent 的 Context 很困難，且往往「一個 Agent + 多個 Tools」就能解決問題。 第三階段：Coding Agent 與 SDK 成熟期 (現在) 作法：使用 Claude Code 或 GitHub Copilot 這類高度可自訂的 Coding Agent。 突破：透過自訂 Instructions 和 SKILLs (流程知識)，不僅能寫程式，還能處理非開發任務。這是最直覺有效的路徑。 AI 時代的 MVP (最小可行性產品) 開發新路徑 過去的軟體開發往往是「從輪子造車」(從底層一行行寫)，風險在於最後一刻才知道客戶喜不喜歡。AI 讓「理想的 MVP 路徑」(滑板車 -> 腳踏車 -> 汽車) 變得成本極低且可行： ...

前言 在進行 Entity Framework 查詢時，當你執行的是「唯讀」操作，卻沒有使用 AsNoTracking() 時，效能會有差距。本篇記錄實際踩雷的經驗——當資料量小時還看不出來，但隨著資料成長，超過預設的 60 秒 Timeout 限制，導致排程工作失敗。 問題情景 某個 .NET Framework 排程工作，定期執行一份複雜的資料查詢： using (var db = new MyDbContext()) { var result = db.Orders .Where(o => o.Status == "Completed") .GroupBy(o => o.CustomerId) .Select(g => new { CustomerId = g.Key, TotalAmount = g.Sum(o => o.Amount), OrderCount = g.Count() }) .ToList(); // 處理 result... } 起初，資料量只有幾千筆，執行速度很快。但隨著程式修改，時間推移，累積到數十萬筆以上，這個查詢開始變得異常緩慢，最終超過預設的 60 秒 Timeout，排程執行失敗。 根本原因：Change Tracking Entity Framework 預設會追蹤查詢結果中的每一個實體： ...