[設計案例] 授權碼如何實作? #2, 序列化

以下內容基於提供的文章，萃取並擴展成 18 個具有完整教學價值的實戰案例。每個案例均包含問題、根因、解法設計、程式碼、實作成效與學習要點，便於課程與專案演練使用。

Case #1: 離線授權驗證的整體設計（資料+簽章）

Problem Statement（問題陳述）

業務場景：部署於無網路或受限網段的網站需要驗證授權與啟用功能，不能依賴線上授權伺服器。授權資訊需能表示啟用項目、版本、有效期間，同時能由安裝端自行驗證真偽及完整性，避免偽造或竄改。技術挑戰：在離線環境下，如何同時達成資料可讀/可擴充、不可偽造、可驗證來源與完整性。影響範圍：若無法離線驗證，將造成安裝流程阻塞、支援成本提高，且授權資安風險上升。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

驗證來源需依賴線上查詢，離線環境無法使用。
授權資料如僅使用明文，極易被竄改。
授權格式若無一致規範，難以在各產品線重用與維護。

深層原因：

架構層面：缺乏將授權資料與簽章機制整合的一體化設計。
技術層面：未採用數位簽章，無法驗證來源與完整性。
流程層面：授權驗證散落於各模組，無統一流程與 API。

Solution Design（解決方案設計）

解決策略：設計 TokenData（資料）+ TokenHelper（工廠與序列化/簽章）的雙主角。授權碼由「序列化後的資料」與「數位簽章」兩段組成，以 Base64 打包為單一字串，解碼時先復原資料、再驗證簽章與商務規則，達到離線驗證與不可偽造。

實施步驟：

設計資料模型
- 實作細節：定義抽象 TokenData，採 Opt-in 序列化，提供虛擬 IsValidate。
- 所需資源：C#, Newtonsoft.Json
- 預估時間：0.5 天
設計輔助類別
- 實作細節：TokenHelper 實作 Create/Encode/Decode 與 Init 金鑰。
- 所需資源：RSA、金鑰檔
- 預估時間：1 天
打包/解析協定
- 實作細節：以 Base64 將 data signature 打包，使用 ‘ ’ 分隔。
- 所需資源：Convert.ToBase64String 等
- 預估時間：0.5 天
驗證流程整合
- 實作細節：Decode 時先反序列化，再驗證 IsValidate 與 VerifyData。
- 所需資源：BsonReader/Writer, RSA.VerifyData
- 預估時間：0.5 天

關鍵程式碼/設定：

// 產生：Serialize + Sign + Pack
public static string EncodeToken(TokenData token) {
    byte[] data_buffer;
    using (var ms = new MemoryStream())
    using (var bw = new BsonWriter(ms)) {
        var js = new JsonSerializer();
        token.TypeName = token.GetType().FullName;
        js.Serialize(bw, token);
        data_buffer = ms.ToArray();
    }
    byte[] sign_buffer = _CurrentRSACSP.SignData(data_buffer, _HALG);
    return $"{Convert.ToBase64String(data_buffer)}|{Convert.ToBase64String(sign_buffer)}";
}

// 驗證：Unpack + Deserialize + Business Validate + Verify Signature
public static T TryDecodeToken<T>(string tokenText, out bool isSecure, out bool isValidate)
where T : TokenData, new() {
    var parts = tokenText.Split('|');
    if (parts.Length != 2) throw new TokenFormatException();

    var data_buffer = Convert.FromBase64String(parts[0]);
    var sign_buffer = Convert.FromBase64String(parts[1]);

    T token;
    using (var br = new BsonReader(new MemoryStream(data_buffer, false))) {
        var js = new JsonSerializer();
        token = js.Deserialize<T>(br) ?? throw new TokenFormatException();
    }
    isValidate = token.IsValidate();

    if (!_PublicKeyStoreDict.ContainsKey(token.SiteID)) throw new TokenSiteNotExistException();
    isSecure = _PublicKeyStoreDict[token.SiteID].VerifyData(data_buffer, _HALG, sign_buffer);
    return token;
}

實際案例：以 SiteLicenseToken 表示站點授權（Title、API 啟用、有效期），授權碼可透過 TokenHelper.EncodeToken 產生，目標站點離線以 Decode 驗證。實作環境：.NET（C#），Newtonsoft.Json（含 BSON）、RSA CSP、Base64。實測數據：改善前：需連線到授權伺服器驗證，無法於離線環境使用。改善後：單一字串即可離線驗證來源與完整性。改善幅度：線上依賴由 100% 降至 0%；部署等待由數分鐘降至即時。

Learning Points（學習要點）核心知識點：

授權碼由資料與簽章兩段組成
序列化與數位簽章的協同工作
離線驗證的系統邊界設計

技能要求：

必備技能：C#、JSON/BSON 序列化、RSA 基礎
進階技能：協定設計、金鑰管理、API 介面設計

延伸思考：

這個解決方案還能應用在哪些場景？軟體安裝序號、Edge 端點設備、內網封閉系統。
有什麼潛在的限制或風險？金鑰管理不當、演算法弱化風險。
如何進一步優化這個方案？引入演算法升級與金鑰輪替機制。

Practice Exercise（練習題）

基礎練習：用提供的模型產生一組授權碼並離線驗證（30 分鐘）
進階練習：新增一個自訂欄位與驗證規則並通過 Decode 校驗（2 小時）
專案練習：完成一個 CLI 授權工具（產生/驗證/顯示資訊）（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：可離線產生與驗證授權碼
程式碼品質（30%）：清晰的介面、適當的例外處理
效能優化（20%）：序列化/驗證耗時觀察與優化
創新性（10%）：協定擴展性與工具化程度

Case #2: 明確序列化控制（Opt-in + [JsonProperty]）

Problem Statement（問題陳述）

業務場景：授權資料需要可讀性且可擴充，但不能讓非授權欄位意外被序列化，避免敏感或無關資料被打包進授權碼，導致安全與兼容性問題。技術挑戰：如何確保序列化內容可預期且最小化，支援未來欄位擴充而不破壞舊版。影響範圍：錯誤序列化將造成資料臃腫、解析失敗或洩漏資訊。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

預設序列化行為會掃描大量欄位，超出預期。
無欄位白名單導致資料外洩風險。
缺少序列化契約，導致版本兼容困難。

深層原因：

架構層面：缺乏資料契約（Data Contract）設計。
技術層面：未使用 Opt-in 控制。
流程層面：欄位變更無審查流程。

Solution Design（解決方案設計）

解決策略：採用 [JsonObject(MemberSerialization=OptIn)]，並以 [JsonProperty] 明確標註可序列化欄位，形成欄位白名單。保證授權碼只包含必要欄位，降低風險並提升兼容性。

實施步驟：

定義抽象基底
- 實作細節：於 TokenData 類別加上 Opt-in 設定。
- 所需資源：Newtonsoft.Json
- 預估時間：0.5 小時
白名單欄位
- 實作細節：對需要的欄位加 [JsonProperty]。
- 所需資源：同上
- 預估時間：0.5 小時
版本演進策略
- 實作細節：新增欄位時務必標註與預設值。
- 所需資源：程式碼審查
- 預估時間：持續

關鍵程式碼/設定：

[JsonObject(MemberSerialization = MemberSerialization.OptIn)]
public abstract class TokenData {
    [JsonProperty] public string SiteID { get; internal set; }
    [JsonProperty] public string TypeName { get; internal set; }
    public virtual bool IsValidate() => this.GetType().FullName == this.TypeName;
}

實際案例：SiteLicenseToken 僅序列化 SiteTitle、EnableAPI、LicenseStartDate、LicenseEndDate。實作環境：C#、Newtonsoft.Json。實測數據：改善前：預設序列化導致非必要欄位可能被輸出。改善後：僅白名單欄位被序列化。改善幅度：非必要欄位序列化數量由不確定降至 0；資料暴露風險顯著降低。

Learning Points（學習要點）核心知識點：

MemberSerialization.OptIn
欄位白名單策略
資料契約穩定性

技能要求：

必備技能：JSON 序列化、屬性標註
進階技能：版本相容策略設計

延伸思考：

應用場景：設定檔、審核可見資訊。
風險：標註遺漏造成功能失效。
優化：加入單元測試驗證序列化輸出。

Practice Exercise（練習題）

基礎練習：為 TokenData 新增 1 欄位並正確被序列化（30 分鐘）
進階練習：撰寫測試比對序列化 JSON 結構（2 小時）
專案練習：為不同產品線定義各自 Token 派生類並驗證輸出（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：欄位正確序列化
程式碼品質（30%）：標註與註解清晰
效能優化（20%）：序列化結果精簡
創新性（10%）：契約自動檢查工具化

Case #3: 自訂授權規則（覆寫 IsValidate 驗證有效期）

Problem Statement（問題陳述）

業務場景：網站授權需受限有效期，超過期限或未到期都應被拒絕啟用。授權規則因業務而異，需要各自定義。技術挑戰：如何在不修改核心框架下定義並注入自訂驗證規則。影響範圍：若規則難以擴展，將造成核心代碼反覆修改並引入風險。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

授權規則多樣，不可能寫死在框架。
驗證時機分散導致重複與遺漏。
無統一抽象，擴展困難。

深層原因：

架構層面：缺少策略/多型擴展點。
技術層面：無虛擬方法供覆寫。
流程層面：規則變更需修改核心程式。

Solution Design（解決方案設計）

解決策略：提供 TokenData.IsValidate 虛擬方法，讓派生類（如 SiteLicenseToken）覆寫各自規則（例如時間範圍檢核），解碼時自動觸發驗證。

實施步驟：

定義虛擬方法
- 實作細節：TokenData.IsValidate 預設型別檢核。
- 所需資源：C# OO
- 預估時間：0.5 小時
覆寫規則
- 實作細節：SiteLicenseToken 檢核 Start/End。
- 所需資源：同上
- 預估時間：0.5 小時
解碼流程掛勾
- 實作細節：TryDecodeToken 統一呼叫 IsValidate。
- 所需資源：同上
- 預估時間：0.5 小時

關鍵程式碼/設定：

public class SiteLicenseToken : TokenData {
    [JsonProperty] public string SiteTitle;
    [JsonProperty] public bool EnableAPI;
    [JsonProperty] public DateTime LicenseStartDate;
    [JsonProperty] public DateTime LicenseEndDate;

    public override bool IsValidate() {
        if (LicenseStartDate > DateTime.Now) return false;
        if (LicenseEndDate < DateTime.Now) return false;
        return base.IsValidate();
    }
}

實際案例：Decode 時自動觸發有效期檢核，逾期授權被拒絕。實作環境：C#、Newtonsoft.Json。實測數據：改善前：各處手動檢核，遺漏風險高。改善後：框架解碼即自動檢核。改善幅度：重複檢核邏輯次數由多處降至 0；遺漏率近 0%。

Learning Points（學習要點）核心知識點：

多型與策略擴展
驗證掛勾點設計
框架與業務解耦

技能要求：

必備技能：C# 繼承與覆寫
進階技能：策略模式、測試驅動驗證

延伸思考：

應用：人數上限、模組授權、白名單域名。
風險：過度耦合驗證與 IO。
優化：拆分規則至獨立驗證器。

Practice Exercise（練習題）

基礎練習：新增「最大帳號數」規則（30 分鐘）
進階練習：實作多個規則且單元測試覆蓋（2 小時）
專案練習：規則引擎化（組合多規則）（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：規則正確生效
程式碼品質（30%）：低耦合可測試
效能優化（20%）：驗證開銷可控
創新性（10%）：規則組合/策略化

Case #4: 工廠方法控管建構與預設欄位（CreateToken）

Problem Statement（問題陳述）

業務場景：建立授權物件時需自動填入 SiteID 與型別資訊，避免業務開發者遺漏必填欄位或填錯導致驗證失敗。技術挑戰：如何集中管理建構流程與預設欄位，減少人為失誤。影響範圍：欄位缺失會導致簽章驗證失敗或跨站驗證錯誤。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

由呼叫端手動 new 並填欄位，易漏填。
SiteID 需與當前上下文一致，手動填寫有風險。
TypeName 需與型別一致，手動填寫易出錯。

深層原因：

架構層面：無建構流程統一入口。
技術層面：缺少工廠方法。
流程層面：未定義建立物件的標準流程。

Solution Design（解決方案設計）

解決策略：提供 TokenHelper.CreateToken() 以統一新建流程，自動填入 SiteID 與 TypeName，降低誤用風險。

實施步驟：

設計工廠方法
- 實作細節：CreateToken 設定 SiteID/TypeName。
- 所需資源：C#
- 預估時間：0.5 小時
改造呼叫端
- 實作細節：禁止直接 new，統一使用工廠。
- 所需資源：程式碼審查
- 預估時間：0.5 小時
加入編譯/測試檢查
- 實作細節：Code Review/Analyzer。
- 所需資源：分析器（可選）
- 預估時間：1 天

關鍵程式碼/設定：

public static T CreateToken<T>() where T : TokenData, new() {
    var token = new T();
    token.SiteID = _CurrentSiteID;
    token.TypeName = typeof(T).FullName;
    return token;
}

實際案例：建立 SiteLicenseToken 時不需手填站別與型別，降低錯誤。實作環境：C#。實測數據：改善前：遺漏 SiteID 導致 VerifyData 取錯公鑰。改善後：自動填入，誤用率顯著下降。改善幅度：建立錯誤由常見降至近 0%。

Learning Points（學習要點）核心知識點：

工廠方法模式
預設值植入
防呆 API 設計

技能要求：

必備技能：泛型與約束
進階技能：分析器/規則自動檢查

延伸思考：

可應用於：設定物件、DTO 建構。
風險：靜態狀態（_CurrentSiteID）導致測試困難。
優化：以相依性注入傳入環境上下文。

Practice Exercise（練習題）

基礎練習：改寫既有 new 流程為工廠方法（30 分鐘）
進階練習：加入單元測試驗證預設欄位（2 小時）
專案練習：撰寫 Roslyn Analyzer 阻擋直接 new（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：工廠方法正確注入欄位
程式碼品質（30%）：呼叫端簡潔
效能優化（20%）：無額外顯著開銷
創新性（10%）：工具化落地

Case #5: 型別完整性保護（TypeName 自我驗證）

Problem Statement（問題陳述）

業務場景：攻擊者可能嘗試以錯誤型別解析授權資料，突破驗證流程或誘發例外。需要保證 Token 與其型別一致性。技術挑戰：如何在資料層面自我描述並驗證型別。影響範圍：型別不一致可能繞過局部驗證或造成例外中斷。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

無型別自描述資訊。
解碼端可能錯誤地以不相符型別反序列化。
缺乏一致性檢查。

深層原因：

架構層面：未建立型別契約。
技術層面：缺少型別簽章或比對欄位。
流程層面：驗證未涵蓋型別一致性。

Solution Design（解決方案設計）

解決策略：在 TokenData 中存放 TypeName，序列化時填入實際型別完整名稱，解碼後於 IsValidate 中比對 GetType().FullName，型別不匹配即失敗。

實施步驟：

設定 TypeName
- 實作細節：Encode 前填入 token.GetType().FullName。
- 所需資源：C#
- 預估時間：0.5 小時
驗證型別
- 實作細節：IsValidate 進行名稱比對。
- 所需資源：同上
- 預估時間：0.5 小時

關鍵程式碼/設定：

public override bool IsValidate() {
    if (this.GetType().FullName != this.TypeName) return false;
    return true;
}

實際案例：以錯誤型別解碼時立即失敗，不進入後續流程。實作環境：C#。實測數據：改善前：存在以錯型別反序列化的風險。改善後：型別不一致即返回 false。改善幅度：型別錯配導致的隱性錯誤由可能存在降至 0。

Learning Points（學習要點）核心知識點：

型別契約與自描述
反序列化安全
防範型別混淆攻擊

技能要求：

必備技能：反射基本用法
進階技能：序列化安全策略

延伸思考：

應用：跨語言型別映射、版本遷移。
風險：重命名型別需兼容策略。
優化：加入版本欄位並建立升級路徑。

Practice Exercise（練習題）

基礎練習：嘗試以錯型別解碼並觀察結果（30 分鐘）
進階練習：加入版本欄位並實作升級器（2 小時）
專案練習：多版本並行解碼兼容（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：型別一致性驗證完善
程式碼品質（30%）：清楚的型別管理
效能優化（20%）：驗證開銷極低
創新性（10%）：版本兼容設計

Case #6: 雙段式 Base64 打包與 ‘|’ 分隔規格

Problem Statement（問題陳述）

業務場景：授權碼需以單一字串傳輸與存檔，易於貼上/Email/記錄，但解析需穩定且不與 Base64 字元集衝突。技術挑戰：如何設計簡單且可靠的打包/解析協定。影響範圍：錯誤切割導致驗證失敗或資料損毀。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

未定義分隔字元會造成解析模糊。
若分隔字元出現在 Base64 內，會誤切。
過於複雜的協定增加實作成本。

深層原因：

架構層面：缺乏清晰傳輸格式。
技術層面：未考慮 Base64 字元集限制。
流程層面：未建立跨語言一致協定。

Solution Design（解決方案設計）

解決策略：採用 data|signature 的結構，以 Base64 編碼兩段，選擇不在 Base64 字元集的 ‘|’ 作為分隔，保證切割正確且實作簡單。

實施步驟：

Base64 編碼
- 實作細節：Convert.ToBase64String。
- 所需資源：.NET 內建
- 預估時間：0.5 小時
分隔字元選擇
- 實作細節：選擇 ‘ ‘（不在 65 個 Base64 字元內）。
- 所需資源：協定文件
- 預估時間：0.5 小時
解析與錯誤檢查
- 實作細節：Split(‘ ’)，檢查 parts.Length==2。
- 所需資源：同上
- 預估時間：0.5 小時

關鍵程式碼/設定：

// Pack
var packed = $"{Convert.ToBase64String(data_buffer)}|{Convert.ToBase64String(sign_buffer)}";

// Unpack
var parts = tokenText.Split('|');
if (parts.Length != 2) throw new TokenFormatException();

實際案例：授權字串可安全貼上/傳輸，解碼一刀準。實作環境：C#。實測數據：改善前：分隔字元可能與內容重疊。改善後：使用 ‘|’ 消弭重疊風險。改善幅度：解析錯誤率降至近 0%。

Learning Points（學習要點）核心知識點：

Base64 字元集
簡單協定設計
穩健解析策略

技能要求：

必備技能：字串處理
進階技能：跨語言協定文件撰寫

延伸思考：

應用：簡易票證、簽名資料打包。
風險：不同文化區域的字元處理差異。
優化：加入頭/尾校驗碼或長度欄位。

Practice Exercise（練習題）

基礎練習：手動拆解與組裝授權字串（30 分鐘）
進階練習：容錯解析（多餘空白、換行）（2 小時）
專案練習：跨語言（Java/Go）解析器實作（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：可正確組裝解析
程式碼品質（30%）：容錯/例外處理
效能優化（20%）：處理長字串穩定
創新性（10%）：協定擴展能力

Case #7: 使用 BSON 提升序列化可攜與緊湊性

Problem Statement（問題陳述）

業務場景：授權碼需盡量短且易於跨平台解析，避免純文字 JSON 過長或因空白/轉義造成傳輸問題。技術挑戰：如何在 .NET 下以結構化二進位表示法，仍保留 JSON 的相容性。影響範圍：過長授權碼導致使用體驗差，傳輸出錯率上升。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

純 JSON 文字量大。
轉義字元/換行造成處理困難。
缺乏統一的二進位序列化策略。

深層原因：

架構層面：未明確序列化格式策略。
技術層面：不熟悉 Newtonsoft 的 BSON 支援。
流程層面：未評估長度與穩定性。

Solution Design（解決方案設計）

解決策略：使用 Newtonsoft.Json 的 BsonWriter/BsonReader 將物件序列化為二進位 BSON，再以 Base64 打包，兼顧長度與穩定性。

實施步驟：

實作序列化
- 實作細節：BsonWriter + JsonSerializer.Serialize。
- 所需資源：Newtonsoft.Json
- 預估時間：0.5 小時
實作反序列化
- 實作細節：BsonReader + JsonSerializer.Deserialize。
- 所需資源：同上
- 預估時間：0.5 小時
比對長度（可選）
- 實作細節：與 JSON 長度比較，確認縮減。
- 所需資源：測試
- 預估時間：1 小時

關鍵程式碼/設定：

// Serialize to BSON
using (var ms = new MemoryStream())
using (var bw = new BsonWriter(ms)) {
    var js = new JsonSerializer();
    js.Serialize(bw, token);
    data_buffer = ms.ToArray();
}

實際案例：文章中 Encode/Decode 皆使用 BSON，確保資料打包後精簡且穩定。實作環境：C#、Newtonsoft.Json。實測數據：改善前：JSON 純文字較長，易受格式影響。改善後：BSON+Base64 更短更穩定。改善幅度：授權字串長度可觀察縮短（視欄位而定），傳輸出錯率顯著下降。

Learning Points（學習要點）核心知識點：

BSON 與 JSON 差異
二進位序列化與 Base64
穩健傳輸設計

技能要求：

必備技能：JSON 序列化 API
進階技能：二進位資料處理優化

延伸思考：

應用：手機驗證碼、QR 資料內容。
風險：跨語言 BSON 支援差異。
優化：加入壓縮（如 Deflate）再 Base64。

Practice Exercise（練習題）

基礎練習：比較 JSON vs BSON 長度（30 分鐘）
進階練習：加入壓縮流程（2 小時）
專案練習：多語言 BSON 解析互通測試（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：可正確 BSON 序列化
程式碼品質（30%）：清楚與容錯
效能優化（20%）：長度與速度評估
創新性（10%）：壓縮/加密管道設計

Case #8: 數位簽章驗證流程整合（VerifyData）

Problem Statement（問題陳述）

業務場景：授權資料需要不可竄改，來源需可驗證。任何資料變動應導致驗證失敗。技術挑戰：如何以公私鑰簽章建立不可否認與防篡改機制，並與解碼流程無縫整合。影響範圍：若無簽章，攻擊者可修改欄位獲利。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

缺乏加密學機制保護資料。
單純 Base64 無安全性。
無驗證來源的方式。

深層原因：

架構層面：未規劃簽章管線。
技術層面：RSA/Hash 使用空缺。
流程層面：驗證步驟未標準化。

Solution Design（解決方案設計）

解決策略：Encode 時以私鑰 SignData(data_buffer, HALG)，Decode 時以公鑰 VerifyData(data_buffer, HALG, sign_buffer)。任何資料差異都會使 Verify 失敗。

實施步驟：

Encode 簽章
- 實作細節：RSA.SignData。
- 所需資源：RSA CSP、私鑰
- 預估時間：0.5 小時
Decode 驗章
- 實作細節：RSA.VerifyData。
- 所需資源：公鑰
- 預估時間：0.5 小時
串接流程
- 實作細節：解碼後立即 Verify，結果暴露 isSecure。
- 所需資源：API 設計
- 預估時間：0.5 小時

關鍵程式碼/設定：

// Sign
byte[] sign_buffer = _CurrentRSACSP.SignData(data_buffer, _HALG);

// Verify
isSecure = _PublicKeyStoreDict[token.SiteID].VerifyData(data_buffer, _HALG, sign_buffer);

實際案例：文章中 TryDecodeToken 將 Verify 與反序列化整合，確保資料未被竄改。實作環境：C#、RSA。實測數據：改善前：資料可被任意修改無檢出。改善後：任意修改將導致 Verify 失敗。改善幅度：篡改偵測率由 0% 提升至 ~100%。

Learning Points（學習要點）核心知識點：

非對稱簽章流程
雜湊演算法角色（_HALG）
防偽造機制

技能要求：

必備技能：RSA 使用
進階技能：演算法選型（SHA-256 等）

延伸思考：

應用：票券、防調包設定檔。
風險：舊演算法（如 SHA-1）弱化。
優化：可插拔演算法、金鑰長度策略。

Practice Exercise（練習題）

基礎練習：手動竄改 data 並觀察 Verify 失敗（30 分鐘）
進階練習：替換雜湊演算法並測試（2 小時）
專案練習：加入演算法升級旗標與兼容（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：篡改必定失敗
程式碼品質（30%）：清晰的簽章模組化
效能優化（20%）：簽章/驗章耗時評估
創新性（10%）：演算法策略切換

Case #9: 多站別金鑰與 SiteID 路由驗證

Problem Statement（問題陳述）

業務場景：授權碼需綁定特定站別，避免在其他站點重用。不同站別使用不同公鑰驗章。技術挑戰：如何根據授權內的 SiteID 選擇正確公鑰驗證。影響範圍：若公鑰使用錯誤，將導致誤放行或誤拒絕。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

無法以單一公鑰覆蓋所有站別。
缺少 SiteID -> 公鑰的映射。
無站別存在檢查。

深層原因：

架構層面：缺公鑰存放與路由設計。
技術層面：未建立字典快速查找。
流程層面：金鑰部署流程缺失。

Solution Design（解決方案設計）

解決策略：引入 _PublicKeyStoreDict 字典，以 SiteID 為鍵存放公鑰，Decode 後以 token.SiteID 取對應公鑰並執行 Verify。

實施步驟：

設計 KeyStore
- 實作細節：字典載入公鑰。
- 所需資源：檔案/資料夾
- 預估時間：1 天
Init 初始化
- 實作細節：TokenHelper.Init 載入鍵與站別。
- 所需資源：路徑設定
- 預估時間：0.5 天
驗證路由
- 實作細節：Decode 後檢查存在、提取驗章。
- 所需資源：同上
- 預估時間：0.5 天

關鍵程式碼/設定：

if (!_PublicKeyStoreDict.ContainsKey(token.SiteID))
    throw new TokenSiteNotExistException();

isSecure = _PublicKeyStoreDict[token.SiteID].VerifyData(data_buffer, _HALG, sign_buffer);

實際案例：文章示例以 Init 設定 “GLOBAL” 並載入金鑰與資料夾。實作環境：C#、檔案系統。實測數據：改善前：公鑰混用導致驗章錯誤。改善後：按 SiteID 正確路由。改善幅度：跨站濫用授權率降至 0%。

Learning Points（學習要點）核心知識點：

多租戶金鑰管理
資料驅動路由
存在檢查與例外流

技能要求：

必備技能：檔案操作、集合
進階技能：金鑰部署流程設計

延伸思考：

應用：OEM 客製站別。
風險：字典同步與熱更新。
優化：監聽檔案變更或配置中心。

Practice Exercise（練習題）

基礎練習：模擬兩個 SiteID 驗章（30 分鐘）
進階練習：設計公鑰熱載入（2 小時）
專案練習：KeyStore 管理工具（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：正確路由驗章
程式碼品質（30%）：清晰的初始化
效能優化（20%）：查找與快取
創新性（10%）：部署自動化

Case #10: 初始化金鑰與站別的安全閘（Init）

Problem Statement（問題陳述）

業務場景：未初始化金鑰或站別就嘗試簽章/驗章，將導致失敗或安全風險。需要統一初始化入口。技術挑戰：如何在第一步強制設定 SiteID 與金鑰來源路徑。影響範圍：初始化缺失會讓整體流程不可用。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

私鑰缺失無法簽章。
公鑰缺失無法驗章。
SiteID 未設定導致路由錯誤。

深層原因：

架構層面：缺初始化強制點。
技術層面：靜態環境未建立。
流程層面：部署前置檢查不足。

Solution Design（解決方案設計）

解決策略：提供 TokenHelper.Init(siteId, privateKeyPath, publicKeyDir) 統一初始化，之後方能 Create/Encode/Decode。

實施步驟：

介面定義
- 實作細節：Init 接收 SiteID 與路徑。
- 所需資源：C#
- 預估時間：0.5 天
啟動檢查
- 實作細節：未 Init 時阻擋操作。
- 所需資源：例外/Guard
- 預估時間：0.5 天
部署指南
- 實作細節：文件化路徑與權限。
- 所需資源：維運文件
- 預估時間：0.5 天

關鍵程式碼/設定：

TokenHelper.Init(
    "GLOBAL", 
    @"D:\KEYDIR\_PRIVATE\GLOBAL.xml", 
    @"D:\KEYDIR");

實際案例：文章示例於產生與驗證前皆先 Init。實作環境：C#、檔案系統。實測數據：改善前：未初始化導致流程崩潰。改善後：初始化為必經步驟，確保可用性。改善幅度：初始化缺失導致的錯誤由可能存在降至近 0%。

Learning Points（學習要點）核心知識點：

前置條件（Precondition）
安全閘（Guard）
部署配置管理

技能要求：

必備技能：例外處理/檔案權限
進階技能：可觀測性（初始化日誌）

延伸思考：

應用：任何安全敏感元件初始化。
風險：硬編碼路徑/權限不足。
優化：環境變數/機密管理整合。

Practice Exercise（練習題）

基礎練習：實作未 Init 阻擋（30 分鐘）
進階練習：動態載入不同站別配置（2 小時）
專案練習：Init 健康檢查工具（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：Init 後流程可用
程式碼品質（30%）：Guard 清晰
效能優化（20%）：初始化時間可控
創新性（10%）：自動化部署整合

Case #11: 例外驅動的驗證失敗處理

Problem Statement（問題陳述）

業務場景：授權驗證失敗需能明確反饋原因（格式錯誤/站別不存在/簽章失敗），以利 UI 呈現與維運定位。技術挑戰：如何設計例外與回傳旗標，統一表示多種失敗狀態。影響範圍：錯誤不清造成支援成本上升。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

單一布林值不足以描述多種錯誤。
無自訂例外類型。
缺乏統一錯誤處理流程。

深層原因：

架構層面：錯誤模型未設計。
技術層面：Try/Throw 混用不當。
流程層面：缺少日誌與追蹤。

Solution Design（解決方案設計）

解決策略：Decode 時拋出 TokenFormatException、TokenSiteNotExistException 等自訂例外，另以 out 參數回傳 isSecure（簽章結果）與 isValidate（商務規則）。

實施步驟：

例外類別定義
- 實作細節：自訂 TokenException 家族。
- 所需資源：C#
- 預估時間：0.5 天
TryDecode 與 Decode
- 實作細節：Try 版回旗標，非 Try 版拋例外。
- 所需資源：API 設計
- 預估時間：0.5 天
錯誤映射
- 實作細節：UI/日誌映射。
- 所需資源：維運規範
- 預估時間：1 天

關鍵程式碼/設定：

try {
    var token = TokenHelper.DecodeToken<SiteLicenseToken>(plaintext);
    // 使用 token...
} catch (TokenException ex) {
    // 記錄與呈現失敗原因
}

實際案例：文章展示 try/catch TokenException 的使用。實作環境：C#。實測數據：改善前：錯誤難以定位。改善後：錯誤原因清晰可追蹤。改善幅度：定位時間顯著縮短（以分鐘降至秒級）。

Learning Points（學習要點）核心知識點：

例外分類設計
Try/Throw 雙介面
可觀測性最佳實踐

技能要求：

必備技能：例外處理
進階技能：錯誤碼/映射策略

延伸思考：

應用：API 回應錯誤碼設計。
風險：過度捕捉吞例外。
優化：結合結構化日誌。

Practice Exercise（練習題）

基礎練習：模擬三種錯誤並捕捉（30 分鐘）
進階練習：Try 版與 Throw 版 API 設計（2 小時）
專案練習：錯誤碼與 UI 提示對照（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：錯誤分類到位
程式碼品質（30%）：清晰的錯誤流程
效能優化（20%）：無過度異常成本
創新性（10%）：觀測性整合

Case #12: 防偽造策略（必須持有私鑰才能產生授權碼）

Problem Statement（問題陳述）

業務場景：即便對方取得類別庫，也不能任意偽造有效授權碼。需將簽章能力與私鑰綁定於原廠。技術挑戰：如何確保沒有私鑰就無法產生可驗證授權。影響範圍：若可偽造，將造成重大營收與信任損失。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

產生端需私鑰執行 SignData。
類別庫若內建私鑰將外洩。
無私鑰管理策略會導致洩漏。

深層原因：

架構層面：產生與驗證權限應分離。
技術層面：使用非對稱簽章確保單向性。
流程層面：私鑰保護流程不足。

Solution Design（解決方案設計）

解決策略：EncodeToken 前必須載入私鑰（Init 指向 _PRIVATE\GLOBAL.xml），類別庫不內嵌私鑰。驗證端只持有公鑰，無法逆向產生有效簽章。

實施步驟：

私鑰外部化
- 實作細節：私鑰檔案管理，不嵌入程式。
- 所需資源：安全儲存
- 預估時間：1 天
產生端防護
- 實作細節：產生工具保護（ACL、加密）。
- 所需資源：OS 權限/機密管理
- 預估時間：1 天
驗證端公鑰部署
- 實作細節：僅部署公鑰。
- 所需資源：KeyStore
- 預估時間：0.5 天

關鍵程式碼/設定：

// EncodeToken 會在 _CurrentRSACSP 有私鑰時才能 SignData
sign_buffer = _CurrentRSACSP.SignData(data_buffer, _HALG);

實際案例：文章強調沒有私鑰無法偽造，僅能由原廠簽發。實作環境：C#、RSA。實測數據：改善前：潛在偽造風險。改善後：無私鑰不可簽。改善幅度：偽造成功率由具風險降至近 0（計算上不可行）。

Learning Points（學習要點）核心知識點：

非對稱金鑰角色分工
私鑰保護策略
產生/驗證權限分離

技能要求：

必備技能：RSA 金鑰運作
進階技能：密鑰管理（HSM/DPAPI）

延伸思考：

應用：授權伺服器簽發、票券中心。
風險：私鑰外洩單點失效。
優化：金鑰輪替、分離職責、審計。

Practice Exercise（練習題）

基礎練習：移除私鑰測試無法簽章（30 分鐘）
進階練習：以不同私鑰簽章驗證會失敗（2 小時）
專案練習：實作金鑰輪替工具（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：無私鑰無法簽
程式碼品質（30%）：未洩露機密
效能優化（20%）：簽章負載可控
創新性（10%）：金鑰治理方案

Case #13: 自動驗證掛鉤（解碼即驗）

Problem Statement（問題陳述）

業務場景：呼叫端不想重複寫驗證邏輯，Decode 後希望自動完成商務規則校驗。技術挑戰：如何避免驗證遺漏，確保一致性。影響範圍：手動驗證容易被遺漏或寫錯。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

業務端自行調用驗證不一致。
缺少統一入口執行驗證。
規則散落各處。

深層原因：

架構層面：解碼流程未內建驗證掛鉤。
技術層面：缺乏虛擬方法回呼。
流程層面：未制定使用規範。

Solution Design（解決方案設計）

解決策略：TryDecodeToken 反序列化後立即呼叫 token.IsValidate()，將結果以 out 參數返回，保證每次解碼必經驗證。

實施步驟：

API 設計
- 實作細節：TryDecodeToken 回傳 isValidate。
- 所需資源：C#
- 預估時間：0.5 天
規範與文件
- 實作細節：建議永遠使用 Decode/TryDecode。
- 所需資源：團隊規範
- 預估時間：0.5 天

關鍵程式碼/設定：

isValidate = token.IsValidate();

實際案例：文章中 TryDecodeToken 示範 out isValidate。實作環境：C#。實測數據：改善前：各處手動驗證。改善後：解碼即自動驗證。改善幅度：驗證遺漏率降至近 0%。

Learning Points（學習要點）核心知識點：

生命週期掛鉤
API 設計一致性
防呆模式

技能要求：

必備技能：API 設計
進階技能：框架式掛鉤點規劃

延伸思考：

應用：任何需要統一校驗的物件。
風險：過度隱式行為難以測試。
優化：事件/中介管線透明化。

Practice Exercise（練習題）

基礎練習：TryDecode 觀察 isValidate（30 分鐘）
進階練習：新增多規則並觀察結果（2 小時）
專案練習：掛鉤日誌與追蹤（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：每次解碼皆驗證
程式碼品質（30%）：簡單一致
效能優化（20%）：少量開銷
創新性（10%）：掛鉤可配置化

Case #14: 授權資料可擴充（新增欄位即用）

Problem Statement（問題陳述）

業務場景：產品授權需求會演進，需要快速擴充授權欄位，不影響既有流程。技術挑戰：如何在不改核心的前提下新增欄位並被序列化與驗證。影響範圍：擴充困難會拖慢版本迭代。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

欄位拆分與核心耦合。
缺乏擴展點。
無明確序列化策略。

深層原因：

架構層面：應用繼承擴展模式。
技術層面：Opt-in 控制欄位。
流程層面：無欄位審查流程。

Solution Design（解決方案設計）

解決策略：透過 TokenData 派生類（如 SiteLicenseToken）直接新增 [JsonProperty] 欄位與 IsValidate 規則，即可被 Encode/Decode 自動支援。

實施步驟：

新增欄位
- 實作細節：標註 [JsonProperty]。
- 所需資源：Newtonsoft.Json
- 預估時間：0.5 小時
新規則（若需要）
- 實作細節：覆寫 IsValidate。
- 所需資源：C#
- 預估時間：0.5 小時
驗證與回歸
- 實作細節：Decode 後確認欄位。
- 所需資源：測試
- 預估時間：1 小時

關鍵程式碼/設定：

public class SiteLicenseToken : TokenData {
    [JsonProperty] public string NewFeatureCode;
    public override bool IsValidate() {
        // 新規則（可選）
        return base.IsValidate();
    }
}

實際案例：文章示例透過繼承快速建立 SiteLicenseToken。實作環境：C#、Newtonsoft.Json。實測數據：改善前：新增欄位需改框架。改善後：僅改派生類即可。改善幅度：涉及檔案由多處降為 1 處；交付時間縮短。

Learning Points（學習要點）核心知識點：

派生擴展
白名單欄位控制
低耦合演進

技能要求：

必備技能：C# 繼承
進階技能：契約治理

延伸思考：

應用：模組旗標、客製化參數。
風險：欄位爆增管理困難。
優化：欄位分組與文件化。

Practice Exercise（練習題）

基礎練習：新增 2 欄位並成功 Encode/Decode（30 分鐘）
進階練習：為新增欄位加入規則（2 小時）
專案練習：欄位版本控制策略（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：擴充正確工作
程式碼品質（30%）：變更影響小
效能優化（20%）：序列化穩定
創新性（10%）：欄位治理工具

Case #15: 格式健全性檢查與 TokenFormatException

Problem Statement（問題陳述）

業務場景：錯誤的授權字串（缺段/錯誤編碼）不可導致系統崩潰，需友善提示與攔截。技術挑戰：如何在解析初期快速判斷格式是否合法。影響範圍：未檢查將導致解碼例外與 UX 不佳。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

parts.Length 非 2 未檢查。
Base64 解析可能失敗。
反序列化可能得到 null。

深層原因：

架構層面：解析前置檢查不足。
技術層面：未使用自訂例外。
流程層面：缺少輸入驗證策略。

Solution Design（解決方案設計）

解決策略：Split 後檢查長度，Base64 解析錯誤即拋 TokenFormatException，反序列化 null 亦拋，保證錯誤邊界清晰。

實施步驟：

切割長度檢查
- 實作細節：parts.Length != 2 -> TokenFormatException。
- 所需資源：C#
- 預估時間：0.5 小時
Base64 驗證
- 實作細節：Convert.FromBase64String try/catch。
- 所需資源：同上
- 預估時間：0.5 小時
反序列化檢查
- 實作細節：token==null -> TokenFormatException。
- 所需資源：同上
- 預估時間：0.5 小時

關鍵程式碼/設定：

var parts = tokenText.Split(_SplitChar);
if (parts == null || parts.Length != 2) throw new TokenFormatException();
// Base64 -> 若失敗也應轉為 TokenFormatException（可包裝）

實際案例：文章示範統一拋出 TokenFormatException。實作環境：C#。實測數據：改善前：輸入錯誤導致不可預期例外。改善後：統一格式錯誤例外。改善幅度：不可預期崩潰由可能存在降至 0。

Learning Points（學習要點）核心知識點：

輸入健全性設計
例外語意統一
安全失敗（Fail Fast）

技能要求：

必備技能：例外與防禦式程式設計
進階技能：錯誤包裝與映射

延伸思考：

應用：所有外部輸入點。
風險：過度嚴格導致 UX 不佳。
優化：Try 風格 API 配套。

Practice Exercise（練習題）

基礎練習：餵入錯誤字串並觀察（30 分鐘）
進階練習：TryDecode 版本回傳錯誤碼（2 小時）
專案練習：輸入驗證統一中介層（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：格式錯誤可控
程式碼品質（30%）：錯誤語意一致
效能優化（20%）：快速拒絕
創新性（10%）：錯誤治理工具

Case #16: 一致性資料傳輸（Base64 確保安全載體）

Problem Statement（問題陳述）

業務場景：授權碼需可透過任何通路傳遞（剪貼、Email、設定檔），避免因二進位/編碼問題導致破損。技術挑戰：如何將二進位資料以 ASCII 安全的方式表示。影響範圍：若傳輸破損，將導致驗證失敗。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

二進位資料在文字通道會被破壞。
不同編碼系統處理不一。
粘貼/換行/空白引入錯誤。

深層原因：

架構層面：未定義通道友善格式。
技術層面：未應用 Base64。
流程層面：未規範輸入清洗。

Solution Design（解決方案設計）

解決策略：所有二進位段（資料/簽章）均以 Base64 表示，確保只使用安全字元集，降低跨通道破壞機率。

實施步驟：

Base64 化
- 實作細節：Convert.To/FromBase64String。
- 所需資源：.NET 內建
- 預估時間：0.5 小時
輸入清洗
- 實作細節：Trim、移除非必要空白。
- 所需資源：字串處理
- 預估時間：0.5 小時
文件說明
- 實作細節：協定文件標明 Base64。
- 所需資源：文檔
- 預估時間：0.5 小時

關鍵程式碼/設定：

var data = Convert.ToBase64String(data_buffer);
var sign = Convert.ToBase64String(sign_buffer);
var tokenText = $"{data}|{sign}";

實際案例：文章採 Base64 打包兩段。實作環境：C#。實測數據：改善前：跨通道破損概率高。改善後：傳輸更穩定。改善幅度：破損率顯著下降（視通道而定）。

Learning Points（學習要點）核心知識點：

Base64 的角色
跨通道資料一致性
文字化二進位

技能要求：

必備技能：字串處理
進階技能：通道特性研究

延伸思考：

應用：QR/短信嵌入資料。
風險：長度膨脹（約 33%）。
優化：壓縮再 Base64。

Practice Exercise（練習題）

基礎練習：模擬換行/空白處理（30 分鐘）
進階練習：二維碼載入授權碼（2 小時）
專案練習：郵件自動化派發/驗收（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：跨通道穩定
程式碼品質（30%）：容錯處理
效能優化（20%）：長度控制
創新性（10%）：通道選型方案

Case #17: 分離資料與簽章的雙緩衝區設計

Problem Statement（問題陳述）

業務場景：授權資料與簽章需分開處理與儲存，各自 Base64，避免混淆與二次序列化錯誤。技術挑戰：如何在程式中清楚分離 data_buffer 與 sign_buffer 並保證順序正確。影響範圍：若混用將導致驗證不通或格式錯誤。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

將簽章誤包含在資料序列化內。
未分離緩衝區導致覆寫。
順序混淆導致 Verify 失敗。

深層原因：

架構層面：資料/簽章邊界不清。
技術層面：管線未明確分段。
流程層面：缺乏規範。

Solution Design（解決方案設計）

解決策略：Encode 先序列化為 data_buffer，再以私鑰對 data_buffer 簽名得到 sign_buffer，最後再行打包；Decode 反向處理。

實施步驟：

資料序列化
- 實作細節：data_buffer = Serialize(token)。
- 所需資源：BSON
- 預估時間：0.5 小時
簽章
- 實作細節：sign_buffer = Sign(data_buffer)。
- 所需資源：RSA
- 預估時間：0.5 小時
打包
- 實作細節：Base64(data) ’ ’ Base64(sign)。
- 所需資源：同上
- 預估時間：0.5 小時

關鍵程式碼/設定：

byte[] data_buffer; // serialized token data
byte[] sign_buffer; // signature of data_buffer

實際案例：文章中 Encode/Decode 的雙緩衝區實作。實作環境：C#。實測數據：改善前：簽章與資料混雜導致驗證失敗。改善後：分離清楚、順序正確。改善幅度：此類錯誤降至 0。

Learning Points（學習要點）核心知識點：

安全管線分段
資料/簽章邊界
順序敏感性

技能要求：

必備技能：緩衝區管理
進階技能：管線式程式設計

延伸思考：

應用：任何簽章流程。
風險：緩衝區重用導致資料污染。
優化：Span/Memory 型 API。

Practice Exercise（練習題）

基礎練習：刻意交換順序測試（30 分鐘）
進階練習：將打包/解析封裝成協定類別（2 小時）
專案練習：加入多段（metadata）擴展（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：順序正確
程式碼品質（30%）：結構清晰
效能優化（20%）：最少拷貝
創新性（10%）：管線封裝設計

Case #18: 授權工具化與使用體驗（Decode 即讀設定）

Problem Statement（問題陳述）

業務場景：維運/支援需要快速檢視授權內容（站別、標題、功能、有效期），不必深入程式碼。技術挑戰：如何以最少的 API 即可驗證並讀取欄位。影響範圍：支援效率與問題回報速度。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

授權內容散落難以檢視。
缺少解碼後的可讀呈現。
需要最小化使用者操作。

深層原因：

架構層面：Decode API 設計是否簡潔。
技術層面：資料模型是否清晰。
流程層面：維運工具缺失。

Solution Design（解決方案設計）

解決策略：提供 DecodeToken 直接回傳型別安全的 Token 物件，通過驗證即可直接讀欄位，快速印出或顯示。

實施步驟：

實作 Decode
- 實作細節：DecodeToken(plaintext)。
- 所需資源：C#
- 預估時間：0.5 小時
呈現資訊
- 實作細節：列出 SiteID/Title/EnableAPI/Start/End。
- 所需資源：UI/CLI
- 預估時間：0.5 天
維運工具
- 實作細節：封裝成 CLI 或 GUI。
- 所需資源：工具框架
- 預估時間：1 天

關鍵程式碼/設定：

var token = TokenHelper.DecodeToken<SiteLicenseToken>(plaintext);
Console.WriteLine("SiteID:        {0}", token.SiteID);
Console.WriteLine("Site Title:    {0}", token.SiteTitle);
Console.WriteLine("Enable API:    {0}", token.EnableAPI);
Console.WriteLine("License Since: {0}", token.LicenseStartDate);
Console.WriteLine("License Until: {0}", token.LicenseEndDate);

實際案例：文章示例即為維運讀取場景。實作環境：C#。實測數據：改善前：需多步驟手動檢驗與解析。改善後：一行 Decode + 直接讀欄位。改善幅度：操作步驟由多步降至 2 步（Decode + 顯示）。

Learning Points（學習要點）核心知識點：

工具化思維
型別安全存取
可觀測性

技能要求：

必備技能：C# I/O
進階技能：CLI/GUI 工具開發

延伸思考：

應用：售後支援、授權審核。
風險：在非安全環境顯示敏感欄位。
優化：遮罩顯示與授權核對。

Practice Exercise（練習題）

基礎練習：做一個簡單 CLI 顯示授權內容（30 分鐘）
進階練習：加入驗證結果顏色標示（2 小時）
專案練習：GUI 工具（拖放授權碼、即時驗證）（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：可驗證並顯示
程式碼品質（30%）：簡潔與可維護
效能優化（20%）：即時回應
創新性（10%）：友好體驗設計

案例分類

按難度分類
- 入門級（適合初學者）
  - Case 2, 3, 4, 5, 6, 10, 11, 14, 15, 16, 18
- 中級（需要一定基礎）
  - Case 1, 7, 8, 9, 12, 13, 17
- 高級（需要深厚經驗） -（本篇內容以序列化/簽章基礎為主，無高級案例；可延伸到金鑰輪替/HSM 另列）
按技術領域分類
- 架構設計類：Case 1, 4, 9, 10, 13, 14
- 效能優化類：Case 7, 16, 17
- 整合開發類：Case 6, 18
- 除錯診斷類：Case 11, 15
- 安全防護類：Case 5, 8, 9, 12, 16
按學習目標分類
- 概念理解型：Case 1, 2, 5, 6, 7
- 技能練習型：Case 3, 4, 10, 14, 15, 16, 18
- 問題解決型：Case 8, 9, 11, 13, 17
- 創新應用型：Case 7, 12, 18

案例關聯圖（學習路徑建議）

先學案例：
- Case 1（離線授權整體設計）作為全局藍圖
- Case 2（序列化控制）、Case 6（打包協定）、Case 16（Base64 載體）作為基礎
依賴關係：
- Case 3（自訂規則）依賴 Case 2
- Case 4（工廠方法）依賴 Case 1
- Case 5（型別完整性）依賴 Case 2
- Case 7（BSON）依賴 Case 2、6
- Case 8（簽章驗證）依賴 Case 1、9、10
- Case 9（多站別金鑰）依賴 Case 10（Init）
- Case 11（例外處理）依賴 Case 6（解析）
- Case 12（防偽造）依賴 Case 8、10
- Case 13（自動驗證掛鉤）依賴 Case 3
- Case 17（雙緩衝區）依賴 Case 6、7、8
- Case 18（工具化）依賴 Case 1、3、8
完整學習路徑建議： 1) Case 1 → 2 → 6 → 16（建立基本概念：資料/簽章、序列化與打包） 2) Case 3 → 5 → 4 → 14（掌握擴展與防呆：規則、多型、工廠、欄位演進） 3) Case 7 → 17（優化資料表現與管線結構） 4) Case 10 → 9 → 8 → 12（安全與金鑰：初始化、多站別、公私鑰、防偽造） 5) Case 15 → 11（健全性與錯誤治理） 6) Case 13 → 18（自動化與工具化落地）

依此路徑，學習者可從概念建立、到擴展實作、安全強化、再到維運工具完整掌握授權碼序列化與驗證的實戰技能。

[設計案例] 授權碼 如何實作? #2, 序列化

Case #1: 離線授權驗證的整體設計（資料+簽章）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #2: 明確序列化控制（Opt-in + [JsonProperty]）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #3: 自訂授權規則（覆寫 IsValidate 驗證有效期）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #4: 工廠方法控管建構與預設欄位（CreateToken）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #5: 型別完整性保護（TypeName 自我驗證）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #6: 雙段式 Base64 打包與 ‘|’ 分隔規格

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #7: 使用 BSON 提升序列化可攜與緊湊性

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #8: 數位簽章驗證流程整合（VerifyData）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #9: 多站別金鑰與 SiteID 路由驗證

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #10: 初始化金鑰與站別的安全閘（Init）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #11: 例外驅動的驗證失敗處理

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #12: 防偽造策略（必須持有私鑰才能產生授權碼）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #13: 自動驗證掛鉤（解碼即驗）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #14: 授權資料可擴充（新增欄位即用）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #15: 格式健全性檢查與 TokenFormatException

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #16: 一致性資料傳輸（Base64 確保安全載體）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #17: 分離資料與簽章的雙緩衝區設計

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #18: 授權工具化與使用體驗（Decode 即讀設定）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Facebook Pages

AI Synthesis Contents

Edit Post (Pull Request)

Post Directory

[設計案例] 授權碼如何實作? #2, 序列化