Bot Checker 回來了!
摘要提示
- Bot Checker 回歸: 作者將自製的 Bot Checker 防機器人功能重新加回部落格
- 技術阻礙: 在 BlogEngine.NET（BE）中因 AJAX 機制介入，插入驗證邏輯比在 Community Server（CS）困難
- 框架差異: CS 處處使用 AJAX；BE 多採 PostBack，唯評論區讀取與預覽較依賴 AJAX
- 程式碼可維護性: 評論編輯器與 BBCODE 預覽區塊的程式碼較混亂，增加整合難度
- 折衷方案: 因不想深度對抗 AJAX，部分邏輯移到前端並採取「能用就好」的簡化處理
- 安全限制: 原始碼可見下，Bot Checker 並非萬無一失，形同半開放式防護
- 風險評估: 作者判斷網站規模及誘因有限，機器人不至於特別針對
- 使用體驗: 題目會自動填入評論欄，使用者可自行刪改不影響送出
- 視覺呈現: 貼文展示了 Bot Checker 題目與回應帶題目的效果截圖
- 另類選項: BE 內建 CAPTCHA 功能疑似存在，但作者未找到啟用方式
全文重點
作者宣布將自製的 Bot Checker 功能重新整合進部落格，並分享在 BlogEngine.NET（BE）環境整合時遇到的技術挑戰與因應策略。相較以往在 Community Server（CS）上新增此功能相對容易，BE 在評論張貼流程中混用了 AJAX，導致需要投入更多時間追蹤資料流程與插入驗證碼的介面。作者指出，雖然 CS 對 AJAX 的依賴更重，但 BE 多數功能採傳統 PostBack，唯獨在評論編輯器與 BBCODE 預覽區塊顯得突兀，且該區域程式結構較為雜亂，使得在該處導入 Bot Checker 更為繁複。
在實作上，作者不願與 AJAX 細節全面對抗，選擇以較務實的方式完成：將部分驗證流程移至前端處理，並在題目產生後直接把答案或題目填入評論欄位中，讓使用者若不想附帶該字串（如「芭樂雞萬歲」）也能自行刪除，不影響送出。此舉雖然降低了機器人攻擊的門檻，因為原始碼攤開後可推測驗證邏輯，防護並非嚴密，但作者依其站點規模與風險評估，認為足以應付現況，且達到降低垃圾留言的目的。
貼文並附上兩張截圖，分別展示了 Bot Checker 題目的呈現，以及回應內容中帶著 Bot Checker 題目的實際效果，讓讀者理解最終使用者體驗。最後，作者提到在追查 BE 程式碼時發現框架中疑似存在內建 CAPTCHA，但未找到正式啟用方式；對於想採用「正統」CAPTCHA 的使用者，建議可自行研究或嘗試開啟該功能。整體而言，本文重點在於分享從框架差異、整合困難、取捨實作到風險管理的完整思考，並提供實務上的使用成果與替代方案提示。
段落重點
回歸與動機
作者開門見山宣布 Bot Checker 功能「終於加回來了」，表達先前嘗試未果的狀況與完成後的輕鬆心情。核心動機是恢復在舊平台（CS）上已經行之有效的防機器人留言機制，讓現行博客環境也能降低垃圾留言侵擾。
為何在 BE 上較難
對比 CS 的「很簡單就加上去」，BE 在評論張貼時使用不少 AJAX 流程，使得要插入驗證邏輯必須一路追蹤非同步資料與前後端交互，增加整合複雜度。雖然 BE 整體偏向中規中矩的 PostBack 模式，但唯有「唯讀回應、文本編輯器、BBCODE 預覽」這些區塊有較多 AJAX 介入，結構也較凌亂，導致作者多次嘗試半途而廢。
取捨與實作策略
為避免深陷 AJAX 細節，作者採「能運作即可」的折衷策略：將部分處理移到前端，題目產生後直接填入評論欄。這種作法讓整合工作量大幅下降，但同時降低了防護強度，因為從原始碼即可窺見驗證邏輯，形同半公開。作者以自身站點規模與攻擊誘因評估風險，決定接受此不完美方案。
使用體驗與範例
貼文附圖展示 Bot Checker 題目及回應帶題目的實際顯示，讓讀者理解操作流程。雖然系統會預先把如「芭樂雞萬歲」的字串放入評論欄，使用者不喜歡可自行刪除，不影響留言送出。此設計在不打擾使用者的前提下提供基本的機器人阻擋效果，兼顧可用性與簡易性。
題外話：BE 內建 CAPTCHA
作者在閱讀 BE 程式碼時發現似乎有 CAPTCHA 元件，但不清楚如何啟用。對需要更嚴謹防護的使用者，建議可嘗試研究與開啟 BE 內建 CAPTCHA，作為比 Bot Checker 更正統且更安全的替代方案。此段也反映出 BE 文件化或可用性上的不足，對開發者而言，探索與配置成本仍待優化。
資訊整理
知識架構圖
- 前置知識：
- 基本的 .NET/ASP.NET WebForms 概念（PostBack、事件生命週期）
- AJAX 基礎（客戶端/伺服端互動、部分渲染）
- BlogEngine.NET 與 Community Server 的部落格留言流程
- Bot/Spam 與人機驗證（CAPTCHA、簡易問答式驗證）的基本觀念
- 前端 HTML/JavaScript 與表單提交流程
- 核心概念：
- Bot Checker：以簡單問答或固定字串驗證避免機器人留言的機制
- CAPTCHA vs. 自製驗證：正統圖形/音訊 CAPTCHA 與輕量自訂問答的取捨（安全性與整合成本）
- AJAX 對驗證流程的影響：留言區採 AJAX 時，驗證邏輯與資料流需同時考量前後端
- 伺服端驗證為本：避免只在 Client Side 驗證導致可被繞過
- 平台差異：Community Server 大量使用 AJAX；BlogEngine.NET 多為 PostBack，唯留言區較依賴 AJAX，造成整合複雜度
- 技術依賴：
- ASP.NET WebForms 的 PostBack 模型與伺服端事件處理
- BlogEngine.NET 留言模組、評論編輯器與 BBCode 預覽的前端腳本
- AJAX 提交流程（前端填值、序列化、伺服端處理、回傳）
- HTML 原始碼可見性對安全的影響（Client Side 預填答案的風險）
- 可選：內建 CAPTCHA 的啟用與配置（文中提及存在但未說明如何開啟）
- 應用場景：
- 部落格或內容平台的留言防灌水/防機器人
- 在既有系統（BlogEngine.NET）中快速補上輕量驗證
- AJAX 化留言區需要嵌入驗證欄位與伺服端檢核
- 過渡方案：在無法立刻導入正統 CAPTCHA 時，先以 Bot Checker 降低垃圾留言
學習路徑建議
- 入門者路徑：
- 了解 Bot/Spam 與人機驗證的基本原理與常見方案（CAPTCHA、問答式）
- 熟悉 ASP.NET WebForms 表單提交與伺服端驗證的基本作法
- 安裝與瀏覽 BlogEngine.NET，找出留言流程與前端欄位
- 嘗試加入最簡單的伺服端問答驗證（避免只在前端檢查）
- 進階者路徑：
- 閱讀 BlogEngine.NET 留言與編輯器的前端/後端程式碼，掌握 AJAX 流程
- 將驗證欄位與 token/question 透過伺服端生成、伺服端儲存（Session/TempData/Hidden + HMAC）
- 實作漸進增強：無 JS 用 PostBack 驗證；有 JS 時以 AJAX 提交但仍伺服端檢核
- 評估與啟用內建 CAPTCHA 或導入成熟套件（含無障礙/可用性考量）
- 實戰路徑：
- 在留言表單加入驗證欄位（問題/答案或 CAPTCHA placeholder）
- 伺服端產生題目與一次性 token，綁定到使用者會話或表單（避免可預測與重放）
- 前端（含 AJAX 提交）確保欄位一併送出；後端統一檢核與回傳錯誤訊息
- 測試：正常流程、關閉 JS、惡意跳過欄位、重放提交、查看 HTML 原始碼可否輕易繞過
- 監控效果並視垃圾量決定是否升級為正統 CAPTCHA
關鍵要點清單
- Bot Checker 概念: 以簡易問答降低機器人留言，成本低但安全性有限 (優先級: 高)
- 伺服端驗證為核心: 所有驗證最終必須在伺服端檢核，避免只靠前端 (優先級: 高)
- AJAX 對整合的影響: 留言採 AJAX 需確保驗證欄位與狀態一起提交並由後端檢核 (優先級: 高)
- BlogEngine.NET 流程差異: BE 多用 PostBack，但留言區 AJAX 使掛接點複雜 (優先級: 中)
- Community Server 對比: CS 廣用 AJAX，經驗可參考但不可直接套用到 BE (優先級: 低)
- 客戶端預填風險: 在前端自動填答案會暴露於 HTML，防禦力幾乎為零 (優先級: 高)
- 問題/答案生成策略: 題目應隨機、短期有效並與會話/Token 綁定 (優先級: 中)
- Token/HMAC 防重放: 使用一次性 Token 或簽章避免被重放或偽造 (優先級: 中)
- 兼容無 JS 場景: 提供非 AJAX 的備援提交流程與錯誤提示 (優先級: 中)
- 編輯器與預覽整合: BBCode/預覽腳本需一併攜帶與提交驗證欄位 (優先級: 低)
- 錯誤處理與 UX: 驗證失敗時清楚提示並保留已輸入的留言內容 (優先級: 中)
- 內建 CAPTCHA 評估: BE 可能內含 CAPTCHA，應研究如何啟用與設定 (優先級: 中)
- 安全性與維運取捨: 輕量 Bot Checker 部署快但可能需後續升級 (優先級: 高)
- 程式碼維護性: 在混雜 AJAX/前端腳本處插入驗證需保持結構清晰 (優先級: 中)
- 監測與調整: 觀察垃圾量與繞過情況，迭代題庫或更換方案 (優先級: 中)
