fix: NinjaFirewall 相容性 — 保護 WAF 設定選項不被重導向
評估 NinjaFirewall (WP Edition) 4.9 的相容性，結論是兩者可共存且
不需要開發 AddOn（該外掛全 codebase 零個 apply_filters('nfw_*') /
do_action('nfw_*')，官方相容手段全在部署層）。但核心有一個隱患必須補。
TMDO_Options_Manager::register_settings_group() 以 pre_update_option_{key}
回傳 $old_value，讓選項不再落地 wp_options、改存專屬設定表。而
NinjaFirewall 的 Full WAF 走 auto_prepend_file，在 WordPress 載入前就以
原生 mysqli 直查 wp_options 取 nfw_options / nfw_rules。一旦這些鍵被
重導向，WAF 會讀不到設定而靜默停止防護 —— 不報錯、不寫 log。
nfw_rules 約 77KB 且 autoload=auto，正是 autoload 瘦身最誘人的目標，
因此這條路徑並非理論風險。
Added
- PROTECTED_OPTIONS 常數與註冊守衛（nfw_options / nfw_rules / nfw_checked），
命中時發出 _doing_it_wrong()。守衛置於方法開頭，全部鍵都被擋時提前返回，
不再建立空的設定表。
- tests/unit/OptionsManagerProtectedTest.php（4 tests / 10 assertions），
鎖住「受保護鍵絕不會被掛上 pre_option_* / pre_update_option_* 攔截」。
- docs/WAF-COMPATIBILITY.md：模式差異、symlink 多租戶部署、WP SaaS 開站
流程與驗證清單、三條開發約束、實測風險矩陣。
Changed
- Migration Wizard 輪詢 500ms → 2s，與四個 stress-test 面板一致。
原本 2 req/s 打同一 REST endpoint，易觸發 WAF rate-limit 與 bot 偵測。
autoload 最佳化不受影響：optimize_autoload() 只改 autoload 欄位、不刪列，
而 Full WAF 的 SELECT * 不看 autoload。
驗證：591 tests / 1166 assertions 通過，PHPCS 零違規，版本一致性 1.0.2。
dev30 於 Full WAF 與 WP WAF 兩種模式下實測，firewall log 中 TMDO 相關
攔截 0 筆。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SdjXAU473eekjPBB8vPVRS
This commit is contained in:
@@ -6,7 +6,7 @@
|
||||
|
||||
## Current state
|
||||
|
||||
- **Version**: 0.1.0 (scaffold + 4 phase 完成 2026-05-15)
|
||||
- **Version**: 1.0.2 (2026-08-15；scaffold + 4 phase 完成於 2026-05-15)
|
||||
- **Phase**: 全 4 phase 已完成
|
||||
- **Source**: 從 `wp-data-optimizer v2.16.0` 提煉
|
||||
|
||||
@@ -287,3 +287,28 @@ AddOn 測試 bootstrap 直接 `require` 核心 plugin 的 `tests/bootstrap.php`
|
||||
- `v0.1.0` — 本 release（Phase 0-4 完成）
|
||||
- `v0.1.1` — Phase 5 follow-up（tests / PHPCS / packaging）
|
||||
- `v0.2.0` — WPDO_ deprecation notice + wpdo → tmdo migration CLI
|
||||
|
||||
---
|
||||
|
||||
## NinjaFirewall 相容性 ✅（2026-08-15，v1.0.2）
|
||||
|
||||
計畫檔：`~/.claude/plans/2meet-data-optimizer-ninjafirewall-effervescent-lighthouse.md`
|
||||
|
||||
- [x] 評估與 NinjaFirewall 4.9 的相容性 → **不需要開發 AddOn**
|
||||
- [x] 診斷 `Cannot retrieve user options from database (#3)` → 與本外掛無關，根因為 symlink 部署
|
||||
- [x] 建立 `/var/www/Studio/.htninja`（symlink-safe 站台錨點，全租戶共用）
|
||||
- [x] dev30 啟用 ninjafirewall，補上缺失的 `nfw_options` / `nfw_rules`
|
||||
- [x] `TMDO_Options_Manager::PROTECTED_OPTIONS` 守衛 + 4 個單元測試
|
||||
- [x] Migration Wizard 輪詢 500ms → 2s
|
||||
- [x] `docs/WAF-COMPATIBILITY.md`
|
||||
- [x] 全套件回歸：591 tests / 1166 assertions OK
|
||||
|
||||
### Lessons learned（WAF）
|
||||
|
||||
- **`__DIR__` 會解析 symlink**。NinjaFirewall Full WAF 用 `dirname(dirname(dirname(__DIR__)))`（`lib/firewall.php:78`）推導站台位置，在 symlink 共享 codebase 的 SaaS 架構下，所有租戶都會被判定成「共享目錄所屬的那個站」，於是連錯資料庫、撈不到自己的 `nfw_options`，回錯誤碼 6（訊息寫作 `#3`）。**per-site 的可靠錨點是 `$_SERVER['DOCUMENT_ROOT']`**（web server 的 root 指令值，不受 symlink 影響），這正是 `.htninja` 的搜尋基準。
|
||||
- **`.htninja` 放在 `dirname(DOCUMENT_ROOT)` 可服務全部租戶**（`firewall.php:47-48` 的第二順位），因為內容以 DOCUMENT_ROOT 動態推導，一份檔案通用。切勿在其中寫 `return` —— `'ALLOW'` / `'BLOCK'` 是有意義的回傳值。
|
||||
- **`NFW_LOG_DIR` 對 WP WAF 模式同樣必要**：L78 的誤判在兩種模式都存在，只是 WP WAF 不用它連 DB，但 log / cache / session 仍會全部寫進共享目錄互相覆蓋。
|
||||
- **WAF 失效是靜默的**。讀不到設定時 `nfw_quit()` 直接返回，不擋任何請求也不寫 log —— 「your site is not protected」是字面意思。因此任何會讓 `nfw_options` 離開 `wp_options` 的機制（例如本外掛的 `register_settings_group()` 重導向）都必須擋在註冊階段。
|
||||
- **`.user.ini` 必須讓 php-fpm worker 可讀**。dev32 那份是 `root:root 0640`，www-data 讀不到 → `auto_prepend_file` 靜默失效、Full WAF 等同沒裝。排查時容易誤判成「WAF 有在跑」，實際上擋下請求的是共享 mu-plugin 的 WP WAF。
|
||||
- **判斷 WAF 是否真的生效，要用會被規則擋的請求實測**（例如 `?x=../../etc/passwd` → 規則 1 → 403），光看首頁 200 或後台無錯誤訊息都不算數。
|
||||
- WP-CLI 完全豁免（`firewall.php:18-23`），所以 CLI 全綠**不能**當作「WAF 與外掛相容」的證據，必須另外走 HTTP 驗證。
|
||||
|
||||
Reference in New Issue
Block a user