承接昨天的內容 :>

今天要把Firebase連上專案，讓專案可以真正意義上的記住使用者是誰。
就在我直接把東西都丟上去後，我問了Claude我的金鑰是否安全
才知道我犯了一個致命的錯誤：絕對不可以把金鑰直接放在專案內！！！

為什麼絕對不能把 Firebase 金鑰放在專案裡？

在建立 Firebase Admin 時，我們會拿到一組包含憑證的 JSON 檔案（例如 serviceAccountKey.json）。很多人會習慣直接把它丟在專案根目錄下，甚至隨手就提交（Commit）上傳到 GitHub，這是非常危險的做法！(就是我 = =)

1. Admin 金鑰權限無上限，且永不過期

Firebase 的 Admin Service Account 擁有整個資料庫的最高管理權限，而且這組金鑰永遠不會過期。只要有人拿到這組金鑰，就可以完全繞過你在 Firestore 設定的所有 Security Rules，任意讀取、篡改或直接清空你的資料庫！

2. GitHub 上有爬蟲 24 小時在秒抓憑證

如果你的專案連結了 GitHub，只要一不小心打了 git add . 將金鑰 Push 上去，GitHub 上的自動化掃描機器人（Scraper Bot）幾秒鐘之內就能抓到你的金鑰並進行惡意濫用。

3. 為什麼只加 .gitignore 還不夠？

本來想說：「那我把 serviceAccountKey.json 加進 .gitignore 不就好了嗎？」

• Git 擋得住，打包擋不住：.gitignore 只能控制 Git 版控，但如果你把整個專案資料夾壓縮成 .zip 檔傳給同學、同事，或是備份到雲端硬碟，金鑰依然會跟著外流。
• 最佳做法：直接把原始的 JSON 金鑰檔案搬離專案資料夾以外（例如放到電腦的家目錄 ~/.keys/）。

最佳解法：使用 Streamlit Secrets (secrets.toml)

改用 Streamlit 內建的 Secrets 管理機制，能一次完美解決三個問題：

1. 資安隔離：.streamlit/secrets.toml 預設就不會進入版控，且原始 JSON 已搬離專案目錄。
2. 完美支援多行字串：能輕鬆裝下 private_key 這種帶有換行符號（\n）的複雜密鑰。
3. 無縫銜接雲端：無論是本機開發，還是未來部署到 Streamlit Community Cloud，完全不需要修改任何程式碼。

結語

今天本來以為可以輕輕鬆鬆的搞定連結database的任務，殊不知遇到了資安漏洞，差點把自己的金鑰拱手讓人，不過與此同時我也學會了 Streamlit Secrets 的管理機制，能夠從錯誤中學習也是一種不錯的經驗。

明天開始就要讓專案正式接上 AI 讓我們的程式老師們動起來~~