前言 公司原本的上線流程最近要走 Azure DevOps 方式上線，我維護的 iOS App 不外乎也要走這個流程。原本測試都沒有太大問題，但上線之後發現 App Groups 功能沒有正確運作，就開始查找問題，最終找到問題所在並解決，記錄一下過程，並延伸相關知識。 Trouble Shooting 一開始覺得很奇怪，這次上線的內容並沒有異動到 App Group 的設定，所以應該跟 source code 沒有太大關係。後來先嘗試在本機 build 一版，結果發現透過這個方式運作正常，但透過 Azure pipeline build 出來的就會發生問題。因此轉向研究 pipeline yaml 的設定是否出現狀況。 先進一步確認透過 Azure pipeline 包出來的 artifacts 內容是否正確，一般而言，iOS App 打包後的成品如下： DistributionSummary.plist ExportOptions.plist YourAppName.ipa Packaging.log 查看 .ipa 我們可以查看 YourAppName.ipa 裡面到底簽入了哪些權限： 解壓縮 .ipa 檔案： unzip YourAppName.ipa -d AppContents 進入 Payload 目錄： cd AppContents/Payload 執行 codesign 指令： codesign -d --entitlements :- YourAppName.app 每個部分的含義是： codesign：呼叫程式碼簽署工具 d：表示 “display”，用於顯示簽署資訊 -entitlements :-：要求工具顯示應用程式中包含的所有權限（entitlements） 這裡的 :- 是一個特殊的語法，表示將輸出導向到標準輸出（stdout） YourAppName.app：要檢查的應用程式套件路徑 如果有正確簽入 App Groups 的權限，應該要有 <key>com.apple.security.application-groups</key> 的蹤跡，但發現透過 Azure pipeline 包出來 .ipa 沒有。 ...

小弟最近要接手管理 APIM 了，會把踩的點記錄下來。 在管理 Kong API Gateway 的過程中，發現在啟用 IP Restriction Plugin 並設置白名單後，該 consumer 仍然驗證失敗。經確認此情況與 IP 置換有關。 該 consumer request 路徑為： Client → Load Balancer → Kong API Gateway → Backend Service 在這樣的架構中，Kong 接收到的 IP 並不是實際的 Client IP，而是來自 Load Balancer 的內部 IP。 經確認： Kong 接收到的 client_ip 顯示為內部網段 IP（例如：以 .254 結尾）。 這些 IP 實際上是 Load Balancer 的 IP。 導致 IP Restriction Plugin 誤判來源 IP，合法用戶被錯誤拒絕。 Nginx 真實 IP 辨識機制 Kong 是建構在 Nginx 之上，利用 Nginx 的 ngx_http_realip_module 模組來從 HTTP Header 中擷取真正的 Client IP，並改寫 $remote_addr。 ...

雖然説這個靜態網頁主要是拿來做個人筆記記錄用，但想到如果有寫錯的地方，誤人子弟又沒有人告知好像也是個問題， 研究了一下，原來有將留言直接串接到指定 GitHub repo 的 Issues 充作留言區 (但必需要登入 GitHub 才能留言。)的方式。 實驗了一下，串接成功，記錄一下過程。 Step 1: 準備 GitHub repo 確認你有一個公開的 GitHub repo，留言將儲存在這個 repo 的 Issues。 因為本站是部署在 GitHub Pages，理當就建立在這個 page 所屬 repo 上。 Step 2: 安裝 Utterances GitHub App 前往 Utterances 的 GitHub App 頁面，將 App 安裝到你的留言 repo。 這裡沒有必要全部授權，只授權單一 repo 即可。 Step 3: 產生 Utterances script 繼續下一步，前往設定頁，依序填寫以下內容： repo 名稱（格式：username/repo） Issue 對應規則（建議選 pathname 或 title） 可自訂 label（如 blog-comment）方便分類 選擇主題色系 將產生 <script ...></script> 複製下來。 Step 4: 整合到 Hugo（PaperMod） 在 Hugo 專案目錄下建立或修改 layouts/partials/comments.html，貼上剛剛產生的的 script。 接著在你的文章裡面啟用 comment: true ...

前言 整理一下在 Kong APIM 架構下，Redis 在快取與限流計數器同步上的應用。 因為之前沒接觸過，僅就目前理解部分紀錄，不會提到太多細節，未來有機會再補充～ Redis 快取的用途 Kong API Gateway 可以 Redis 來做快取，主要目的是可以快速回應重複的 API 請求，讓資料變動不頻繁的 API 可以直接回傳快取內容，可減少後端服務壓力。 限流計數器的同步需求 如果系統有對 consumer 限流需求，記錄在 db 是一個選項，但這樣就必須所有 gateway 的節點都跟 db 建立連線，且不適用於 dbless 或是 hybrid mode 的架構。 dbless 是指 data plane 的設置透過 kong.yml 來配置，每次配置都需要重啟服務。 hybrid mode 則是將 Control Plane 和 Data Plane 分離，CP 負責管理與同步設定，DP 專注於流量代理。DP 不直接連資料庫，只從 CP 接收設定。相反地，傳統模式沒有明確區分 DP 和 CP。每一台 Kong 節點同時扮演 CP 和 DP 的角色，也就是說，每個節點都可以管理設定（新增/修改服務、路由、插件等），這是 CP 的功能。每個節點也都會處理用戶端 API 請求，這是 DP 的功能，所有節點也都直接連接到資料庫。 ...

在 2025 年 6 月，科技圈熱烈討論法源公司指控 Lawsnote（七法公司）未經授權爬取其法律資料庫內容，構成著作權侵權及違反刑法第359條。以下依爭點，整理判決核心內容： 一、民事判決：損害賠償計算基礎 法院區分三類資料性質，採用不同請求權基礎： 法規沿革： 經刑事判決認定屬《著作權法》第7條「編輯著作」，受著作權保護。 請求權基礎：民法第 184 條第 1 項前段（故意侵權）。 法規內容與附件： 刑事判決未認定為著作，但屬「電磁紀錄」。 請求權基礎：民法第 184 條第 2 項（違反刑法第 359 條「無故取得他人電磁紀錄」之保護性法律）。 二、刑事判決核心爭點 爭點一：「法規沿革」是否受著作權保護？ 被告抗辯： 法規沿革屬政府公文，不具著作權；縱有編排，因表達方式有限（思想與表達合併原則），不應受保護。 法源公司遲至 109 年 11 月才禁止爬蟲，此前行為不構成侵權。 法院認定： 採用「最低程度創作」標準，比對法源公司與政府機關（如科技部、立法院）的沿革表述差異（例如條號範圍、主管機關變動、施行日期等）。 法源公司對資料進行「層次化選擇與編排」，呈現獨特性與原創性，非機械式羅列，故屬《著作權法》第7條保護之編輯著作。 爭點二：被告行為是否構成「合理使用」？ 原告主張： 被告以商業目的（Lawsnote 為收費服務）100% 複製沿革資料，非少量引用或轉化性使用，嚴重損害原告市場價值。 被告主張： 法規沿革屬政府應公開資訊，法源公司未收費提供，使用不損其利益。 Lawsnote 核心價值為搜尋功能，非沿革資料本身，對原市場影響甚微。 法院裁判理由： 利用目的：純商業行為（收費服務）。 使用量：100% 複製。 市場影響：以低價與原告競爭，剝奪授權機會，造成實質損害。 不符合理使用，被告抗辯駁回。 爭點三：爬蟲行為是否構成侵權？ 原告主張： 被告於 107–110 年間撰寫 6 支爬蟲程式，從法源網站下載共 331,524 筆資料（含沿革、內容及附件），用於 Lawsnote 資料庫。 行為逾越法源《使用規範》禁止之自動化查詢與重製範圍。 被告抗辯： 政府網站未完整保存歷史法規，爬取法源僅為便捷與完整性，不構成侵權。 法院認定： 抽樣比對確認下載資料與法源內容「逐字相符」。 未獲授權且違反使用規範，構成著作權侵害。 三、未決爭議與批判性分析 （一）法規資料的公共性 vs. 著作權歸屬 法源公司承接司法院數億元標案維護法規資料，但判決未釐清： 政府委外產出之法規資料，著作財產權應歸屬公部門或企業？ 具公益性質的法規資料，是否可由民間企業專有？ （二）損害賠償計算的合理性爭議 法院以法源公司「建置成本」作為賠償基準，但學說與實務指出： ...