本卡屬 FR-114 資安修正（母卡 CM-2019），第 5 批子集 C 卡 5C-4，修 SUMMARY #82（M04-3）／#83＝#136（M04-7／M19-3）／#84（M04-8）／#103（總表 §3.2-11）／#125（M04-9）。#82／#83 高，#84／#103／#125 中。五件都在 jedi-common、分屬五支不同檔，各自獨立但都不大，同一個 worktree 一次做完最有效率。計畫在 docs/features/FR-114-2609-security-fix-dispatch/batches/plan-b5C.md「卡 5C-4」段。

問題是什麼（白話）

#82：使用者密碼若含雙引號（強密碼常見），寫進紀錄檔時只被遮蔽一半，另一半明文留在資料庫裡長達 90 天——現有遮蔽工具假設密碼不會有雙引號，ab"cd 這種密碼會被誤判成在第一個引號就結束。

#83（＝ #136）：任何登入帳號在任何清單頁把「每頁筆數」改成超大數字，就會把整張資料表一次撈出來；連續操作幾次就能讓全體客戶的系統一起停止回應。#136 是同一根因在設備清單頁的具體表現——修好共用層這一支，兩件一次解決。

#84：客戶環境的設定值若打錯字，程式認不得就會悄悄退回「開發模式」的紀錄設定——開發模式會把七類紀錄多接一條「寫進資料庫」的路徑，正式模式完全沒有這條路徑。

#103：系統紀錄寫進資料庫這件事若失敗，錯誤會往上冒、連帶把使用者原本要做的事也弄壞——目前純粹靠處理順序運氣「沒事」。2026-09-20 複查發現風險比原評估更大：commit 4bf7906（CM-1920）「只轉送稽核事件與 ERROR、prod/stg 加上資料庫紀錄」這個改動讓這條完全沒有錯誤處理的路徑，現在也在正式環境上跑。三位審查者與首腦一致認為這不是資安問題（沒有攻擊者可觸發的路徑），也沒有「無窮寫入迴圈」的疑慮。

#125：兩種維運紀錄被寫死成最高詳細度，紀錄量爆炸吃掉硬碟空間（已修 3 處、剩 2 處未修）。不是資安問題（這兩種紀錄只寫檔案、不進資料庫），但吃硬碟。

首腦核對：

• jedi-jedi-common/jedi_common/utils/common_utils.py:145-159 — mark_password()，正則值的部分寫成 "[^"]*"，不認得跳脫的雙引號
• jedi-jedi-common/jedi_common/interfaces/schema/common.py:13 — page_size = fields.Int(missing=25)，沒有 validate.Range(max=...) 上限
• jedi-jedi-common/jedi_common/interfaces/schema/common.py:12 — page 欄位對照組：validate.Range(min=1) 下限有做，只有上限被漏掉
• jedi-jedi-common/jedi_common/logger/config_logger.py:75 — dictConfig(_CONFIGS.get(RUN_ENV, logging_config_dev))，認不得的值目前退回開發模式設定
• jedi-jedi-common/jedi_common/logger/db_log/db_handler.py:30-51 — emit() 整支函式完全沒有 try/except
• jedi-jedi-common/jedi_common/logger/config_prod.py:82/:87 — pymongo.event_loggers 與 sqlalchemy.orm 兩個 logger 類別的 level 都寫死 DEBUG

工作區

• 套件側：在 /Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security/<套件目錄>（branch fix/security-b1）改，只動自己那支套件的子目錄、只 git add 該子目錄下的檔。 本卡對應單一套件 jedi-common，worktree 建議 wt-fix-b5C-common。

在哪裡

jedi-jedi-common/jedi_common/utils/common_utils.py:145-159    mark_password()，值的部分正則 "[^"]*" 不認跳脫雙引號，#82
jedi-jedi-common/jedi_common/utils/common_utils.py:139-142    _SECRET_KEY_PATTERN，比對 key 名稱的部分，不要動
jedi-jedi-common/jedi_common/handler/handler.py:44    mark_password 呼叫點一
jedi-log/jedi_api_log/error_tracking/masking.py:33-34    呼叫點二，dict/list 先序列化成 JSON 字串再過這支
jedi-jedi-common/jedi_common/interfaces/schema/common.py:13    page_size = fields.Int(missing=25)，無 max 上限，#83／#136 核心
jedi-jedi-common/jedi_common/interfaces/schema/common.py:12    page 欄位對照組，下限有做
jedi-jedi-common/jedi_common/interfaces/schema/common.py:16-18    RequestMetaSchema，全站分頁請求共用的基底
jedi-asset/jedi_asset/api/serializers/device.py:31    DevicePageQueryRequest，#136 實際落點（繼承 RequestMetaSchema）
jedi-jedi-common/jedi_common/logger/config_logger.py:75    dictConfig fallback dev，#84 要改的行
jedi-jedi-common/jedi_common/logger/config_logger.py:30    RUN_ENV = os.getenv("RUN_ENV", "dev")
jedi-jedi-common/jedi_common/logger/config_logger.py:34-38    _CONFIGS 三個合法值 dev/stg/prod
jedi-jedi-common/jedi_common/logger/config_logger.py:28-29    既有註解：出貨機器過去實際依賴這個預設值，改之前要先確認裝機腳本與出貨設定已明確設定 RUN_ENV，且順手把這段過時註解更新成目前現況
jedi-jedi-common/jedi_common/logger/db_log/db_handler.py:30-51    emit() 整支函式，#103，完全沒有 try/except
jedi-jedi-common/jedi_common/logger/db_log/db_handler.py:39    datetime.strptime(record.asctime, ...)，record.asctime 由前一個 handler 就地補上，同檔 :23-25 已有註解說明掛載順序限制
jedi-jedi-common/jedi_common/logger/db_log/db_handler.py:51    system_log_service.add_system_log(log_dto)，寫入資料庫那一行
jedi-jedi-common/jedi_common/logger/config_prod.py:80-84    pymongo.event_loggers，level 寫死 DEBUG（:82），#125
jedi-jedi-common/jedi_common/logger/config_prod.py:85-89    sqlalchemy.orm，level 寫死 DEBUG（:87），#125
jedi-jedi-common/jedi_common/logger/config_prod.py:33    app handler 本身的 level（也是 DEBUG，但這是 handler 層級不是 logger 類別，不要動這行）

怎麼修

D-b5C-6／D-b5C-7 決策者已裁照建議，含「先查證再動手」但方向已定。