別擔心，我們在 PowerShell 裡手動強制開啟 TLS 1.2 ，就可以輕鬆搞定。

絕招一：強制開啟 TLS 1.2 下載法

請複製以下這段程式碼，整段直接貼進你的 PowerShell 視窗裡面執行：

PowerShell

# 1. 強制讓 PowerShell 使用 TLS 1.2 加密協定
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

# 2. 重新嘗試下載安裝檔
Invoke-WebRequest -Uri "https://github.com/microsoft/go-sqlcmd/releases/latest/download/sqlcmd-windows-amd64.msi" -OutFile "$env:USERPROFILE\Downloads\sqlcmd.msi"

# 3. 執行安裝
Start-Process msiexec.exe -ArgumentList "/i `"$env:USERPROFILE\Downloads\sqlcmd.msi`"" -Wait

執行之後，畫面上應該會彈出上面的截圖。

絕招二：繞過 IE 增強式安全性封鎖

如果用了第一招還是失敗，甚至跳出討人厭的 Internet Explorer 紅色警告，那就代表你抓到幕後黑手了！這是 Windows Server 惡名昭彰的「 IE 增強式安全性設定（ IE ESC ）」在作怪。

因為 PowerShell 在下載檔案的時候，背後會偷偷調用 Internet Explorer 的核心元件，而 Server 的安全機制預設會把外面所有的網站（ 包括 GitHub ）通通鎖死，當成大魔王在防防禦。

既然系統的安全性指令一直擋路，我們就改用「 全指令、不調用 IE 網頁核心 」的方法來下載，直接繞過這個煩人的限制。

請在 PowerShell 中執行這段全新的指令：

PowerShell

# 1. 強制開啟 TLS 1.2
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

# 2. 使用微軟官方下載中心（保證存在的 x64 穩定版網址）
$webClient = New-Object System.Net.WebClient
$url = "https://go.microsoft.com/fwlink/?linkid=2142258"
$output = "$env:USERPROFILE\Downloads\MsSqlCmdLnUtils.msi"
$webClient.DownloadFile($url, $output)

# 3. 執行安裝
Start-Process msiexec.exe -ArgumentList "/i `"$output`"" -Wait

這次執行完之後，畫面就不會再跳出那些紅色的警告。它會非常低調、靜悄悄地下載完成，接著直接彈出 sqlcmd 的安裝視窗。你同樣只要動動手指，跟著點下一步完成安裝即可。

最後再次提醒，安裝完畢後，一樣要關掉並重新打開一個新的 PowerShell 或 cmd 視窗，系統的環境變數才會生效。

大家在網站或手機 App 登入帳號時，有沒有想過，你的密碼和資料是怎麼在網路世界裡安全傳遞的？今天我們要來聊聊一個保護你我隱私的幕後功臣，它的名字叫 PKCE。

PKCE 全名是 Proof Key for Code Exchange，大家通常把它讀作 Pixie（就是小精靈的那個英文發音）。它是 OAuth 2.0 這個登入標準機制的安全擴充功能。簡單來說，它就像是幫你的行動 App 或單頁式網頁應用程式（SPA）請了一位動態保鏢，專門防止壞人中途攔截你的登入憑證。

PKCE 是如何運作的？

傳統的登入方式需要一組固定的秘密鑰匙（Client Secret），但如果把這把鑰匙藏在手機 App 或前端網頁裡，很容易就被厲害的駭客挖出來。 PKCE 的聰明之處，就在於它每次登入都用「臨時隨機抽樣」的方式，流程主要分為四個步驟：

1. 產生驗證碼： 你的手機 App 或網頁會在本地端隨機亂數產生一組高密度的字串，這組密碼學字串叫做 code_verifier。
2. 生成挑戰碼： 接下來，系統會把這組字串拿去進行雜湊運算（通常是 SHA-256 演算法），再經過編碼轉換成另一組字串，叫做 code_challenge。
3. 發送請求： 你的 App 會把這組挑戰碼和運算方法，一起送到官方的授權伺服器，大喊一聲「我要登入！」
4. 驗證與核發： 當 App 拿到授權碼，準備跟伺服器換取真正能通行的 Token 時，必須交出第一步產生的原始驗證碼。伺服器會在後端用同樣的方法算一次，確認跟當初的挑戰碼一模一樣，才會點頭放行。

為什麼我們需要 PKCE ？

如果沒有 PKCE 的保護，當授權碼在網路跳轉回傳的途中，很容易被惡意軟體或中間人側錄攔截。駭客只要偷到這個授權碼，就能假冒你的身份去跟伺服器換取存取權限。

網頁後端伺服器因為躲在暗處，可以安全地藏好秘密鑰匙，但手機 App 是公開在外的客戶端，根本沒辦法安全地藏東西。 PKCE 透過每一次登入時「動態出題、動態對答案」的機制，確保發起請求和最後拿 Token 的是同一個合法的 App。這樣一來，壞人就算在半路偷到授權碼，沒有原始的驗證碼也只能乾瞪眼，完全無法盜用！

工程師的私房補丁日誌： AppScan 安全漏洞大作戰

看完了上面的小精靈防護機制，順便來瞧瞧我們這次為了應付 AppScan 安全檢查，在後端默默做了哪些升級。這絕對不是在敷衍檢查，這是為了愛與和平。

核心變更項目

關於 PKCE 漏洞修補，我們擴充了 OAuthProvider 介面，新增了 Supports PKCE() bool 與 Exchange(…oauth2.AuthCodeOption) 功能。現在 Entra ID 會乖乖回傳 true ，而交大 NYCU 則會回傳 false 。登入處理器會自動產生一組驗證碼並發送 S256 挑戰碼，回呼處理器則會負責把驗證碼傳給 Exchange 進行核對。

關於 Cookie 檔安全，我們在前一次的提交中，就已經把驗證 Cookie 檔通通綁上 SameSite=Strict 機制了。

關於 API 安全標頭，我們加入了 AddAPISecurityHeaders 中介軟體，強制執行以下防禦：

• Cross-Origin-Resource-Policy 設為 same-origin
• Strict-Transport-Security 設為 max-age=31536000; includeSubDomains
• Cache-Control 設為 no-store 搭配 Pragma 設為 no-cache
• Referrer-Policy 設為 strict-origin-when-cross-origin

AppScan 漏洞修補成績單

以下是這次的戰果，我們把所有紅字都變成綠色的勾勾了。

• OAuth Implicit Grant 缺 PKCE 漏洞： 中級風險，修復狀態為已完成。
• Cookie 的 SameSite 設定不當： 中級風險，修復狀態為已完成。
• API 缺少 CORP 標頭： 中級風險，修復狀態為已完成。
• 可快取的 SSL 網頁： 低級風險，修復狀態為已完成，透過 Cache-Control 防禦。
• 缺少 Referrer-Policy 標頭： 低級風險，修復狀態為已完成。
• 缺少 HSTS 標頭： 低級風險，修復狀態為已完成。

Addresses AppScan security findings for the backend.

Changes

• PKCE (OAuth Implicit Grant flaw): OAuthProvider interface extended with SupportsPKCE() bool and Exchange(…oauth2.AuthCodeOption). Entra ID returns rue; NYCU returns alse. Login handler generates a verifier and sends S256 challenge; Callback handler passes verifier to Exchange.
• SameSite=Strict: Auth cookies already fixed in previous commit (SameSiteStrictMode).
• API Security Headers (AddAPISecurityHeaders middleware):
  • Cross-Origin-Resource-Policy: same-origin
  • Strict-Transport-Security: max-age=31536000; includeSubDomains
  • Cache-Control: no-store + Pragma: no-cache
  • Referrer-Policy: strict-origin-when-cross-origin

AppScan Findings Addressed

Finding	Severity	Status
OAuth Implicit Grant (missing PKCE)	M	Fixed
Cookie SameSite improper	M	Fixed
CORP header missing on API	M	Fixed
Cacheable SSL pages	L	Fixed (Cache-Control: no-store)
Missing Referrer-Policy	L	Fixed
Missing HSTS	L	Fixed

要讓 ＯＷＡＳＰ ＺＡＰ 成功掃描登入後的管理介面，最關鍵的任務就是讓 ＺＡＰ 掌握身分驗證機制，不然它爬到一半被系統踢登出，掃描就等於白做了。

在 Ｄｏｃｋｅｒ 環境中執行 ＺＡＰ，主要有兩種方式，一種是透過瀏覽器操作圖形介面，另一種是直接用指令跑自動化掃描。既然需要設定登入資訊這麼複雜的操作，強烈建議使用第一種圖形介面，操作起來就跟在本機裝軟體一模一樣。

以下是完整的設定與執行步驟。

方法一：啟動 Web Swing 圖形介面（推薦，方便設定登入）

Docker 版本的 ZAP 內建了 Web Swing 功能，可以把 GUI 畫面渲染到網頁上。

1. 執行 Docker 指令

打開你的終端機（Terminal 或 PowerShell），輸入以下指令：

Bash

docker run -u zap -p 8080:8080 -p 8090:8090 -i owasp/zap2twig:latest zap-webswing.sh

參數解析：

• -p 8080:8080：ZAP Web 界面的連接埠（透過瀏覽器訪問）。
• -p 8090:8090：ZAP 本身的 Proxy 連接埠。
• owasp/zap2twig:latest：這是包含完整週邊工具的 ZAP 映像檔。

2. 開啟瀏覽器操作

指令跑起來後，打開你本機的瀏覽器，輸入以下網址：

http://localhost:8080/zap/

你就會在網頁裡看到完整的 ZAP 操作視窗。接下來，你就可以按照前面教的步驟去設定 Context、Authentication 和 Users。

方法二：使用命令列 (CLI) 進行自動化掃描

如果你已經把登入的設定檔匯出成 .context 檔案，或者管理介面可以單靠 Token 驗證，你也可以直接用指令讓 Docker 裡的 ZAP 跑完就結束。

執行 Baseline Scan（基本弱點掃描）指令：

Bash

docker run -t owasp/zap2twig:latest zap-baseline.py -t https://your-target-site.com

Docker 環境下的關鍵注意事項（非常重要）

當 ZAP 住在 Docker 容器裡時，有兩個常見的「坑」需要注意：

1. 目標網站也在你的本機 (Localhost) 嗎？

如果你的管理介面網站也是用 Docker 跑在本機，或是跑在本機的 http://localhost:3000：

• 不能在 ZAP 裡面填 localhost，因為對 ZAP 容器來說，localhost 指的是 ZAP 自己。
• 解決方法：將網址改為 http://host.docker.internal:3000/，這樣 ZAP 才能穿透容器存取到你本機的服務。

2. 資料如何儲存與匯出？

Docker 容器一旦關閉，裡面的設定和掃描報告就會消失。如果你想把掃描報告存回本機電腦，必須掛載資料夾（Volume）：

Bash

# 在指令中加入 -v 參數，將本機的資料夾與容器內同步
docker run -u zap -v /path/to/your/local/dir:/home/zap/reports:rw -p 8080:8080 -i owasp/zap2twig:latest zap-webswing.sh

你的管理介面網站目前是部署在雲端測試機，還是也同樣跑在你的本機 Docker 環境中呢？

要讓 OWASP ZAMP (Zed Attack Proxy) 成功掃描「登入後」的管理介面，核心關鍵在於讓 ZAP 掌握身分驗證（Authentication）機制，這樣它才不會在掃描到一半時因 Session 過期而被踢登出。

以下是實現這個目標最完整、最推崇的設定流程：

步驟一：使用 Context（上下文）鎖定目標

1. 打開 ZAP，在左側的 Sites 樹狀目錄中，找到你的網站。
2. 右鍵點擊網站根目錄 -> Include in Context -> 選擇 New Context（或預設的 Default Context）。
3. 這會打開 Context 設定視窗。在 In Scope 頁面中，確保你的網站 URL 已被勾選。

步驟二：錄製登入步驟並設定登入指標

ZAP 需要知道「怎麼登入」以及「怎麼判斷目前是登入還是登出狀態」。

1. 錄製登入請求

• 建議使用 ZAP 內建的瀏覽器（點擊右上角的瀏覽器圖示，如 Chrome/Firefox）手動操作一次登入。
• 登入成功後，回到 ZAP 的 History 標籤頁。
• 找到那筆發送帳號密碼的 POST 請求（通常是 /login 或 /auth）。
• 右鍵點擊該請求 -> Flag as Context -> 選擇你的 Context -> Form-based Auth Login Request。

2. 設定登出指標（Logged Out Indicator）

ZAP 在掃描時如果看到特定的字眼，就知道自己被踢登出了（必須重新登入）。

• 在剛剛內建瀏覽器的畫面上，找到「登出後才會出現的文字」（例如：請先登入、Login、帳號或密碼錯誤）。
• 在 ZAP 的 Context 設定視窗中，切換到 Authentication 頁面。
• 將驗證方法改為 Form-based Authentication（如果剛剛有正確 Flag，這裡會自動帶入登入 URL 和參數）。
• 在下方 Logged Out Indicator 欄位中，填入剛剛找到的登出關鍵字（支援正則表達式，例如：.*請先登入.*）。

步驟三：設定使用者憑證（Users）

讓 ZAP 知道要用哪組帳密去登入管理介面。

1. 在 Context 設定視窗中，點選 Users 頁面。
2. 點擊 Add 新增一個使用者（例如：admin）。
3. 勾選 Enabled，並輸入管理員的 Username 與 Password。

步驟四：設定強制使用者模式（Forced User Mode）

這是最關鍵的一步，強迫 ZAP 的所有掃描工具（包含 Spider 和 Active Scan）都帶著這個身分去跑。

1. 在 Context 設定視窗中，點選 Forced User 頁面。
2. 在下拉選單中，選擇你剛剛在 步驟三 建立的那個使用者（admin）。
3. 點擊 OK 儲存並關閉 Context 設定視窗。
4. 啟用強制模式：在 ZAP 主介面上方的工具列，找到一個「鎖頭搭配一個小人」的圖示（Forced User Mode），把它點擊下去（讓它呈現鎖定/啟用的狀態）。

步驟五：開始安全掃描

現在 ZAP 已經具備自動登入的能力了，你可以開始掃描管理介面：

1. Spider（蜘蛛爬蟲）：
   • 在左側 Sites 樹狀目錄，右鍵點擊管理介面的資料夾（例如 /admin）。
   • 選擇 Attack -> Spider…。
   • 在彈出的視窗中，User 欄位記得選擇你設定的 admin，然後點擊 Start Scan。這時 ZAP 就會帶著登入身分去爬取所有管理員才能看到的頁面。
2. Active Scan（主動掃描/弱點掃描）：
   • 爬蟲結束後，一樣右鍵點擊該目錄 -> Attack -> Active Scan…。
   • 同樣確保 User 選擇 admin，點擊 Start Scan，ZAP 就會開始對管理介面進行漏洞狂轟猛炸。

進階小撇步 (如果管理介面有驗證碼/雙因子認證 CAPTCHA / 2FA)：

自動化工具通常無法破解驗證碼。如果遇到這種情況，建議改用 Replacer 功能 或 Scripting 直接把手動登入後取得的 Cookie 或 Bearer Token 塞給 ZAP 瀏覽器，但缺點是 Token 過期就必須手動更新。

你在設定 Form-based Auth 的過程中，有遇到特定的登入阻礙（例如前端加密、Token 驗證）嗎？

GUI 很麻煩, 改用 terminal 比較方便

Shell Tail second dry-run log 35 lines
Found Java version 17.0.19
Available memory: 15863 MB
Using JVM args: -Xmx3965m
307 [main] INFO org.parosproxy.paros.Constant – Copying default configuration to /home/zap/.ZAP/config.xml
381 [main] INFO org.parosproxy.paros.Constant – Creating directory /home/zap/.ZAP/session
382 [main] INFO org.parosproxy.paros.Constant – Creating directory /home/zap/.ZAP/dirbuster
382 [main] INFO org.parosproxy.paros.Constant – Creating directory /home/zap/.ZAP/fuzzers
383 [main] INFO org.parosproxy.paros.Constant – Creating directory /home/zap/.ZAP/plugin
Jul 06, 2026 3:33:16 AM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
Downloading add-on from:
https://github.com/zaproxy/zap-extensions/releases/download/commonlib-v1.42.0/commonlib-release-1.42.0.zap
Downloading add-on from:
https://github.com/zaproxy/zap-extensions/releases/download/authhelper-v0.40.0/authhelper-beta-0.40.0.zap
Downloading add-on from:
https://github.com/zaproxy/zap-extensions/releases/download/selenium-v15.51.0/selenium-release-15.51.0.zap
Add-on downloaded to: /home/zap/.ZAP/plugin/authhelper-beta-0.40.0.zap
Add-on downloaded to: /home/zap/.ZAP/plugin/commonlib-release-1.42.0.zap
Add-on downloaded to: /home/zap/.ZAP/plugin/selenium-release-15.51.0.zap

Tasks
—
│ │ Subagents
│ No subagents
│
│ Shell Commands
│ ❯ ◎ Run ZAP full scan in background, logging output [detached background]

改用 AI 代勞進行 scan 超方便, 完全不需要去學習如何使用.

以下為你整理出最流暢的申請 4 大步驟：

第一步：建立新專案

1. 前往 Google Cloud Console。
2. 登入你的 Google 帳號。
3. 點擊左上角的專案下拉選單，選擇 「新建專案」 (New Project)。
4. 輸入專案名稱（例如：MyAwesomeApp），然後點擊 「建立」。

第二步：設定 OAuth 同意畫面 (OAuth Consent Screen)

這是使用者在登入你的 App 時會看到的授權畫面，必須先設定它。

1. 點擊左側選單的 「API 和服務」 > 「OAuth 同意畫面」。
2. 選擇 User Type：
   • 外部 (External)： 開放給所有 Google 帳號（一般應用程式選這個）。
   • 內部 (Internal)： 僅限你 Google Workspace 組織內的成員（企業內部工具選這個）。
3. 填寫基本資料：應用程式名稱、使用者支援電子郵件 以及 開發人員聯絡資訊，完成後點擊「儲存並繼續」。
4. 範圍 (Scopes)： 設定你想拿到的權限（如 email, profile）。初次測試可以先不選，直接跳過。
5. 測試使用者 (Test Users)： 如果你的專案還在「測試中」階段，必須在這裡新增你自己的測試 Email，否則其他帳號會無法登入。

第三步：建立憑證 (Credentials) 取得密鑰

這一步會生成你的 Client ID 和 Client Secret。

1. 點擊左側選單的 「憑證」 (Credentials)。
2. 點擊上方的 「+ 建立憑證」 > 「OAuth 用戶端 ID」。
3. 選擇你的 應用程式類型（例如：網頁應用程式、Android、iOS 等）。
4. 填寫核心網址（以網頁應用程式為例）：
   • 已授權的 JavaScript 來源： 你的網站首頁（例如：http://localhost:3000 或 https://yourdomain.com）。
   • 已授權的重新導向 URI： 使用者登入成功後，Google 把 Code 送回你網站的後端路由（例如：http://localhost:3000/auth/google/callback）。※ 注意：這裡一定要設定精準，否則會噴 redirect_uri_mismatch 錯誤。
5. 點擊 「建立」。

恭喜！ 畫面上會跳出你的 用戶端 ID (Client ID) 和 用戶端密鑰 (Client Secret)。請立刻複製並妥善保管，密鑰絕對不能外流！

第四步：切換為「生產模式」（選填）

在開發測試階段，你的專案狀態會是「測試中 (Testing)」，只有你在第二步設定的測試小夥伴能登入，且可能會有不安全應用的警告。

• 當你的 App 準備好上線時，回到 「OAuth 同意畫面」，點擊 「發布應用程式」 (Publish App) 切換為正式生產模式。
• 備註：如果你申請了敏感權限（如讀取使用者的 Gmail 私訊），Google 會需要人工審查，可能需要幾天到幾週的時間。

我有測試環境 domain name 與正式環境 domain name 要申請2組 OAuth 2.0 用戶端 ID 嗎? 還是同一組ID即可。

建議申請「2 組獨立的 OAuth 2.0 用戶端 ID (Client ID)」。

雖然在技術上，Google 允許你在同一組 Client ID 的「已授權的重新導向 URI」中，同時填入測試環境與正式環境的網址，但非常強烈建議分開申請。原因如下：

1. 安全性考量（最重要的原因）

• 憑證外流風險： 測試環境通常防護較弱，可能會有較多開發人員、測試人員接觸到設定檔。如果測試環境的 Client Secret（用戶端密鑰）不小心外流，且你兩邊用同一組 ID，攻擊者就能利用外流的密鑰去染指或偽造正式環境的登入請求。
• 網址白名單污染： 萬一測試環境網址被惡意劫持或存在漏洞，它與正式環境共享同一個 OAuth 信任圈，會帶來額外的安全隱患。

2. Google 審查與「發布狀態」限制

Google Cloud 專案的 OAuth 同意畫面有分兩種狀態：

• 測試中 (Testing)： 只有白名單內的「測試使用者」可以登入，且登入時會跳出「未經驗證的應用程式」警告。
• 生產模式 (In Production)： 開放給所有 Google 帳號登入。如果使用了敏感權限（Scopes），還需要通過 Google 的人工驗證。

如果你只用一組：

當你的專案為了正式環境切換成「生產模式」並送交審查時，如果你的網址白名單裡還夾帶了 project-name.test.example.com.tw（而且通常測試環境在外網無法被 Google 審查官順利連上），這可能會導致你的 Google 審查被拒絕 (Rejected)，因為 Google 要求生產模式下的網址必須是公開、真實且符合規範的。

最佳實作做法 (Best Practice)

為了架構清晰與安全，你可以選擇以下兩種配置方式：

方案 A：在同一個 Google Cloud 專案下，建立 2 個 Client ID（推薦，最方便）

在同一個專案的「憑證」頁面中，點擊兩次「建立憑證 > OAuth 用戶端 ID」：

• 第一組 ID（命名：Project Name – Test）：
  • 重新導向 URI 填：https://projectname.test.example.com.tw/oauth2/callback
• 第二組 ID（命名：Project Name – Prod）：
  • 重新導向 URI 填：https://projectname.example.com.tw/oauth2/callback

這樣你在程式碼的環境變數（.env）中，測試機就讀取測試的 ID/Secret，正式機就讀取正式的 ID/Secret，彼此互不干擾。

方案 B：建立 2 個獨立的 Google Cloud 專案（最嚴謹）

• 專案一：PorjectName-Test（專案狀態保持在 Testing，方便開發隨時測試）
• 專案二：PorjectName-Prod（專案狀態切換為 Production，專門用來跑正式上線與 Google 審查流程）

總結： 為了維護系統的安全防線與後續維護的便利性，請務必為測試與正式環境分開申請獨立的憑證！

應用程式是哪種類型, Vue 3 + Vite

既然你的前端技術棧是 Vue 3 + Vite，在架構設計上你首先需要釐清一個關鍵問題：你的應用程式有沒有後端（Backend，如 Node.js, Python, Go）？

這會直接決定你如何實作 Google OAuth。以下為你說明這兩種情境與實作方式：

情境一：有後端（推薦，最安全）

這是最正統的做法。Vue 3 只負責顯示「登入按鈕」，使用者點擊後會引導到 Google 登入，登入成功後 Google 會把驗證碼（Authorization Code）傳給你的後端，由後端去跟 Google 交換 Token，並簽發你網站自己的 JWT 給 Vue 3。

在這種模式下，你的 OAuth 2.0 用戶端 ID 類型要選擇：「網頁應用程式」 (Web Application)。

Vite / Vue 3 前端實作步驟：

目前社群上最推崇、封裝最完整的套件是 vue3-google-signin。

安裝套件：Bash

npm install vue3-google-signin

在 main.js 或 main.ts 中初始化：

import { createApp } from 'vue'
import App from './App.vue'
import GoogleSignInPlugin from 'vue3-google-signin'

const app = createApp(App)

app.use(GoogleSignInPlugin, {
  // Vite 的環境變數必須以 VITE_ 開頭
  clientId: import.meta.env.VITE_GOOGLE_CLIENT_ID,
})

app.mount('#app')

在畫面上建立登入按鈕 (Login.vue)：

<script setup>
import { GoogleLogin } from 'vue3-google-signin'

const handleLoginSuccess = (response) => {
  // 這裡會拿到 Google 回傳的 code 或 credential
  console.log("Google 登入成功:", response);

  // 【關鍵】將這個 response (含 code) 用 axios 傳送給你的後端
  // axios.post('https://projectname.example.come.tw/api/auth/google', { code: response.code })
}

const handleLoginError = () => {
  console.error("Google 登入失敗")
}
</script>

<template>
  <div class="login-container">
    <h2>入口網登入</h2>
    <GoogleLogin :callback="handleLoginSuccess" :popup-type="'CODE'" @error="handleLoginError" />
  </div>
</template>

情境二：純前端（SPA 單頁應用，無後端）

如果你的 Vue 3 是一個完全靜態的網站，沒有任何自己的後端資料庫，單純只想確認「他是誰」或者想在前端呼叫 Google API（例如讀取他的 Google Calendar）。

在這種模式下，你的 OAuth 2.0 用戶端 ID 類型一樣選擇：「網頁應用程式」。但流程會走「隱含授權 (Implicit Flow)」，直接在前端取得 access_token。

安全警告： 因為純前端沒有秘密可言，你的 Client Secret 絕對不能寫在 Vue 3 的原始碼或 .env 裡（因為打包後任何人都能看光）。在 Google Console 建立憑證時，這種模式通常不需要用到 Client Secret。

前端設定差異：

如果你是用上面提到的 vue3-google-signin，在按鈕上就不要加 :popup-type="'CODE'"，它預設會直接在前端回傳一串 JWT（身分憑證），你可以直接解開它來取得使用者的 Email 和姓名：

JavaScript

import { decodeCredential } from 'vue3-google-signin'

const handleLoginSuccess = (response) => {
  // 直接在前端解密 Google 回傳的使用者資訊
  const userData = decodeCredential(response.credential)
  console.log("使用者資料:", userData) // 包含 email, name, picture
}

搭配你上一題的測試/正式環境，Vite 該如何設定？

因為你有兩個環境，請在 Vue 3 專案根目錄建立兩個環境變數檔案：

1. .env.development (測試環境用)程式碼片段VITE_GOOGLE_CLIENT_ID=你的測試環境_CLIENT_ID.apps.googleusercontent.com
2. .env.production (正式環境用)程式碼片段VITE_GOOGLE_CLIENT_ID=你的正式環境_CLIENT_ID.apps.googleusercontent.com

當你執行 vite preview 或 vite build 時，Vite 就會自動根據環境抓取正確的 Client ID，完美對應到正式環境與測試環境了！

這裡幫大家整理了 4 個超實用的方法，不管是想要神級的操作體驗，還是懶得安裝任何軟體的速成法，這篇通通有。

方法 1 ： VS Code 神級流暢體驗（強烈推薦）

如果你平常就在用 Visual Studio Code 寫程式，這絕對是最頂的選擇，可以享受一邊打字、旁邊畫面一邊即時更新的快感。

1. 打開 VS Code ，到擴充功能市場搜尋並安裝 PlantUML 這個套件。
2. 注意，這裡有一個重要的小跟班需要安裝。因為 PlantUML 畫圖需要 Graphviz 的協助，請打開命令提示字元輸入 winget install Graphviz 來快速搞定它。
3. 如果真的懶得在電腦安裝 Graphviz 怎麼辦？也可以直接到 VS Code 的設定裡搜尋 plantuml.server ，把它改成連到官方的線上伺服器來幫你畫圖。
4. 萬事俱備後，打開 .puml 檔案，按下 Alt + D ，右邊就會跳出即時預覽畫面。

方法 2 ： JetBrains 宇宙（ IntelliJ 、 PyCharm 專屬）

如果你是 JetBrains 系列 IDE 的忠實粉絲，根本不用離開視窗，裡面就自帶強大功能。

1. 點選 File 進入 Settings ，接著找到 Plugins 區塊。
2. 搜尋 PlantUML Integration 並點擊安裝。
3. 把 IDE 重新啟動。
4. 接下來只要打開任何 .puml 檔案，右邊就會自動長出專屬的預覽視窗，完全不用操心。

方法 3 ： 獨立 Java 檔案（免安裝開發工具）

如果不想為了看張圖就開啟笨重的開發工具，也可以用官方提供的輕量級 Java 小工具。

1. 請先確保電腦裡有安裝 Java 執行環境。
2. 到 PlantUML 官方網站 下載 plantuml.jar 檔案。
3. 打開命令提示字元，切換到下載的資料夾，輸入 java -jar plantuml.jar -gui 這一行指令。
4. 畫面上就會跳出一個小巧的視窗，只要選好放 .puml 檔案的資料夾，每次只要存檔，它就會自動幫你刷新圖片。

方法 4 ： 線上免安裝（終極懶人法）

如果只是臨時要看一下檔案，連一秒鐘都不想浪費在安裝上，那就直接交給瀏覽器吧。

• 官方線上伺服器：直接把程式碼複製貼上到 PlantUML Web Server 就能立刻看到結果。
• 網頁編輯器： PlantText 是一個非常受歡迎的線上即時編輯器，畫面好看而且專為 PlantUML 設計，非常適合臨時救急。

在 Windows 執行 ssh 顯示錯誤訊息

C:\Users\max>ssh 4.216.213.123
Bad permissions. Try removing permissions for user: BUILTIN\\Users (S-1-5-32-545) on file C:/Users/max/.ssh/vm-max-pc-key.pem.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'C:\\Users\\max/.ssh/vm-max-pc-key.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "C:\\Users\\max/.ssh/vm-max-pc-key.pem": bad permissions
azureuser@4.216.213.123: Permission denied (publickey).

在使用 Windows 系統連線到遠端伺服器的時候，是不是常常遇到 SSH 跟你鬧脾氣？

畫面跳出一大串警告，寫著 WARNING UNPROTECTED PRIVATE KEY FILE ，然後無情地拒絕連線。這其實不是你的伺服器壞掉，而是 SSH 的安全機制太過傲嬌。它覺得你的金鑰檔案太過公開，像是把家裡鑰匙直接貼在大門口一樣危險，所以故意裝作不認識你。

這個問題通常是因為金鑰檔案的權限開太大，導致系統內的其他使用者也能讀取。要解決這個尷尬的狀況，有兩種快速的方法可以馴服它。

第一種方法是使用命令提示字元。

請開啟命令提示字元，並依序輸入以下指令。記得將路徑換成自己的金鑰檔案路徑。

第一步是取消繼承權限，指令為

icacls C:\Users\your_username\.ssh\my_key.pem /inheritance:r

第二步是重新給予自己完整的控制權限，指令為

icacls C:\Users\your_username\.ssh\my_key.pem /grant:r your_username:F 

第二種方法是使用圖形介面，適合喜歡用滑鼠點擊的人。

請打開檔案總管，找到金鑰檔案。在檔案上按右鍵選擇內容，切換到安全性標籤，接著點擊進階。

在進階安全性設定視窗中，點擊停用繼承，並選擇將繼承的權限轉換為此物件的明確權限。

最後在權限項目清單中，找到 Users 這個群組並將它移除，只留下自己的使用者帳號擁有存取權限。點擊套用並確定就完成了。

設定完成之後，再次嘗試原本的連線指令，應該就能順利連上伺服器。如果還是失敗，可以嘗試在指令中明確加上減 i 參數，例如

ssh -i C:\Users\your_username.ssh\my_key.pem user@1.2.3.4 

這樣就能成功登入了。

如果你現在用的是 Vue 3 搭配 Element Plus，而你在拿掉的瞬間，你的網頁基本上就半身不遂了。

• 短期（建議）： 維持 Element Plus，接受 unsafe-inline Medium 風險，專注業務功能。
• 中期： 若資安掃描壓力大，評估 Naive UI 替換（相同 Vue 生態、學習成本低）。
• 長期： 新專案直接選 React + shadcn/ui 或 React + Mantine，避免此問題。

兩大資安大哉問： 到底能不能直接拔掉？

我們先把問題拆成兩個層面來看。

1. 在 FastAPI 設定 CSP 跟在 Nginx 設定，有差嗎？

答案是： 完全沒有差別。

瀏覽器是很單純的，它只看最後收到的 HTTP response header。 不管這個資安政策是後端框架 FastAPI 吐出來的，還是前端大門 Nginx 塞給它的，對瀏覽器來說都長得一樣。

目前專案只有在 FastAPI 設定，那就繼續留在那邊就好，不需要特地搬家。

2. 移除 unsafe-inline 之後，Element Plus 還能動嗎？

答案是： 絕對會壞掉，而且壞得很難看。

如果你的 CSP 政策直接移除了 unsafe-inline，下面這些畫面上最亮眼的主角會集體罷工：

• el-select / el-dropdown： 下拉選單直接迷路，位置飛到九霄雲外或是乾脆隱形。
• el-tooltip / el-popover： 滑鼠移過去原本該跳出的提示，現在比你的前任還要冷淡，完全沒反應。
• el-dialog： 彈出視窗直接彈歪，跟你的預期完全對不上。
• el-table 固定列： 說好要固定的欄位，現在放飛自我跟著一起滾動。

為什麼會這樣？ 因為這些元件在運作時，JavaScript 會在幕後瘋狂計算畫面的座標，然後直接把 style="top: 200px; left: 150px;" 這種類型的行內樣式塞進 HTML 標籤裡。

當你把 unsafe-inline 拿掉，瀏覽器就會化身鐵面判官，只要看到這種行內樣式，一律當成非法入侵直接封鎖。 結果就是你的 CSP 報告看起來滿分，但使用者的畫面看起來像一場災難。

那難道無解了嗎？ 現代資安的標準解法

好消息是，我們不需要為了資安把整個 Element Plus 換掉（ 畢竟換框架是會出人命的 ）。 在 CSP Level 3 的現代標準中，資安政策已經被細分得更聰明了。

以前的 style-src 是一刀切，但現在我們可以把「 標籤 」和「 屬性 」分開管理。

你可以試試看這套完美的資安配置：

HTTP

Content-Security-Policy: style-src-elem 'self' https://cdnjs.cloudflare.com; style-src-attr 'unsafe-inline';

這段設定的意思其實就是跟瀏覽器講悄悄話：

• style-src-elem ‘self’： 只要有人想用 <style> 標籤或外掛惡意 CSS 檔案來劫持網頁，一律給我擋掉！ 這招直接封鎖了最危險的 CSS 注入攻擊。
• style-src-attr ‘unsafe-inline’： 至於 HTML 標籤裡面的 style="..." 屬性，我們就開個特權給它過吧。

改前 vs 改後 戰力分析

這樣改到底差在哪裡？ 我們直接看對比：

• <style> 注入攻擊： 改前是允許的（ 超危險 ），改後直接封鎖（ 安全 ）。
• 外掛惡意 CSS 檔案： 改前是允許的（ 超危險 ），改後直接封鎖（ 安全 ）。
• Element Plus 動態定位： 改前正常，改後依然正常運作。
• 資安掃描器的警告： 改前會跳出黃牌警告，改後警告直接消失。

結論

想兼顧資安跟漂亮的 UI，不需要直接把 unsafe-inline 趕盡殺絕。

透過 style-src-elem 和 style-src-attr 的分工合作，你既能把大門關緊防範黑客，又能留個小窗讓 Element Plus 的元件繼續正常跳舞。 這才是現代工程師優雅的解決之道。

結論上來說，改用

在 ＵＸ 的設計討論中，我們常常會遇到一個經典的靈魂考驗：到底要用切換分頁（Toggle）還是全部攤開（No-toggle）？

最近我們團隊為了「回覆功能（Reply）」與「延伸請求（Extend）」這兩個操作，展開了一場尊嚴與智慧的拉鋸戰。

原本的設計是分成兩個分頁切換，但經過一番激烈的腦力激盪後，我們決定給 Toggle 一張好人卡，全面改成 No-toggle 的直接攤開設計。結果，代誌不是憨人想得那麼簡單，我們很快就被現實給打臉了。

為什麼有些地方適合全部攤開

當初我們會決定把功能全部攤開，是因為回覆功能是每一次都要用的核心主角，而延伸請求是極少使用的附屬配角。

我們以為把兩者同時顯示在畫面上，可以減少使用者的點擊次數，達到直覺的效果。

理想很豐滿，現實很骨感：同時顯示的災難

當我們把回覆框和延伸請求同時大剌剌地擺在畫面上時，原本預期的貼心設計，卻變成了使用者的認知混亂。

這兩個功能本質上其實是互斥操作。當使用者同時看到這兩個輸入區塊，大腦就會開始打結，誤以為這兩個動作是可以同時進行的，或者搞不清楚自己現在到底是在回覆，還是在發出延伸請求。

這種畫蛇添足的設計，不但沒有降低負擔，反而讓畫面變得複雜，讓使用者產生了我是誰、我在哪、我要填哪裡的哲學思考。

世紀大和解：還原回覆與展延切換按鈕

經過一場深刻的反省，我們決定痛改前非，正式宣布：還原回覆與展延切換按鈕！

我們發現，互斥操作就應該保持獨立顯示。不要為了自以為是的體貼，就把所有東西都塞進同一個畫面裡。

不過，這次重回 Toggle 的懷抱，我們要做得更精緻，而不是單純退回原點：

• 讓主要操作隨時待命：確保最核心的回覆功能在視覺上依然是第一優先。
• 清晰的模式切換：透過更明確的切換按鈕設計，讓使用者一秒看懂現在點下去會發生什麼事。
• 維持界面的乾淨俐落：把不常使用的延伸請求好好的收納起來，只有在使用者明確需要的時候才召喚它出來。

最終結論

經過這次的瘋狂甩尾調整，我們再次驗證了一個道理：世界上沒有絕對完美的 ＵＸ 設計，只有最適合當下情境的選擇。

當兩個操作具有互斥性質時，勇敢地使用切換按鈕吧！把互斥的操作獨立開來，這種不讓使用者誤會、乾淨俐落的設計，才是真正能讓使用者用得順心、給出五星好評的體貼設計。

不要錢，OWASP ZAP 完全免費且開源。

它是開放網路應用程式安全計劃（OWASP）旗下的旗艦專案，不論是個人、企業內部測試還是商業用途，都可以自由下載並免費使用完整功能，沒有任何隱藏付費牆。

自架弱點掃描工具主要分為「主機/網路層」與「網站/應用程式層」兩種需求。推薦以下幾款業界最主流、成熟的免費與開源自架方案： [1]

1. 主機與網路層弱點掃描

• OpenVAS：企業級開源弱點評估工具，是目前功能最強大的免費主機掃描器之一，具備完整的漏洞資料庫與排程掃描功能。
• Nmap：網路探測與安全性稽核的基石，主要用於主機存活性與連接埠掃描，可搭配 NSE（Nmap Scripting Engine）執行基礎弱點檢測。 [1, 2]

2. 網站應用程式弱點掃描 (Web)

• OWASP ZAP：由國際權威組織維護的最佳免費網頁應用程式弱點掃描器。非常適合整合在開發流程（CI/CD）中，能自動檢測常見的 SQL Injection、XSS 等漏洞。
• Nikto：輕量級的命令列開源網頁伺服器掃描器，能快速找出伺服器危險檔案與過時版本。 [1, 2, 3, 4]

3. 開發原始碼掃描 (DevSecOps)

• SonarQube：針對原始碼進行靜態分析（SAST）的熱門工具，社群版（Community Build）免費且容易上手，適合在自架伺服器上檢測代碼安全缺陷。
• OWASP Dependency-Check：專注於軟體供應鏈安全，能自動掃描專案中套件（如 Maven, npm）的已知漏洞。 [2, 5]

建議策略：
若要檢測作業系統與網路設備，優先部署 OpenVAS；若是針對網頁應用程式安全，則推薦安裝 OWASP ZAP。

[1] https://www.ckmates.com

[2] https://www.cloudsecurity.com.tw

[3] https://ithelp.ithome.com.tw

[4] https://zh.wikipedia.org

[5] https://www.linktech.com.tw

要透過 Docker 快速自架 OWASP ZAP，最推薦的方式是直接使用官方維護的映像檔（Image）。依照您的使用情境，您可以選擇以下其中一行指令來執行：

方案 A：啟動「瀏覽器介面版」(Web Swing UI) — 推薦！

這會在背景啟動 ZAP，並開啟一個網頁版的圖形介面，您只需用瀏覽器連過去就能直接操作，不需要安裝任何本機軟體。

docker run -u zap -p 8080:8080 -p 8090:8090 -d ghcr.io/zaproxy/zaproxy:stable zap-webswing.sh

• 如何使用：開啟瀏覽器輸入 http://localhost:8080/zap/ 即可看到操作畫面。
• 連接埠說明：8080 是 Web 介面連線埠；8090 是 ZAP 預設的代理伺服器（Proxy）連線埠。

方案 B：直接對目標網站執行「自動化基準掃描」(Baseline Scan)

如果您不需要看畫面，只想直接對特定網站進行快速的安全性點檢（約數分鐘內完成）並在終端機看結果：

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://example.com

• 注意事項：請將 https://example.com 替換為您自己擁有權限的測試網站網址。

方案 C：直接對目標網站執行「深度全功能掃描」(Full Scan)

這會執行更深度的網頁爬蟲與主動攻擊測試（包含 XSS、SQLi 等），耗時較長：

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-full.py -t https://example.com

接下來，您可以決定如何處理掃描後的資料。如果您有興趣，我們可以討論：

• 如何將掃描後的 HTML/PDF 漏洞報告 自動匯出到您的本機資料夾
• 如何設定 ZAP 的 API Key 以確保 Docker 容器的安全防護
• 如何將這行指令整合進您現有的 CI/CD 自動化流程

請告訴我您想朝哪個應用方向深入操作？

非常抱歉，前一則回覆給錯了腳本名稱。在 OWASP ZAP 的官方 Docker 映像檔中，深度全功能掃描的正確腳本名稱是 zap-full-scan.py（中間多了一個 -scan），而且它已經被設定在環境變數中，不需加上 /zap/ 前綴。 [1, 2, 3, 4]

請直接複製以下經過修正的正確指令至您的 C:\Users\your-account> 終端機執行：

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py -t https://your-app-domain.com

進階實用建議：將報告儲存至本機

由於您的目標網址是一個 dashboard（儀表板頁面），執行 zap-full-scan.py 會耗費較長時間（進行深度爬蟲與主動漏洞攻擊）。 [1]

若您希望在掃描完成後，直接在您的 Windows 本機資料夾看到 HTML 報告，建議使用 -v 參數掛載路徑，並加上 -r 指定檔名： [2, 5]

docker run -v %cd%:/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py -r report.html -t https://your-app-domain.com

執行完成後，您就可以直接在 C:\Users\your-account> 資料夾下找到 report.html 報告檔案。 [5, 6]

當您成功啟動掃描後，接下來您可能會遇到與目標網站特性的相關調整。我們可以繼續討論：

• 如果該 Dashboard 需要 帳號密碼登入 才能看到內容，該如何代入 Cookie 或帳密進行掃描
• 如何設定 -m 參數來 限制掃描時間，避免因為網站太大而掃描過久
• 如何看懂終端機輸出顯示的 漏洞風險等級 (High/Medium/Low) [7, 8, 9, 10]

請試試看修正後的指令，並告訴我您是否需要設定 登入權限掃描 呢？

[1] https://www.zaproxy.org

[2] https://forums.docker.com

[3] https://github.com

[4] https://github.com

[5] https://www.zaproxy.org

[6] https://stackoverflow.com

[7] https://www.zaproxy.org

[8] https://groups.google.com

[9] https://www.youtube.com

[10] https://www.zaproxy.org

如果你使用的是 PowerShell 視窗，請輸入以下指令：

ssh -T -i “$env:USERPROFILE.ssh\your-key_ed25519” git@github.com

如果你使用的是傳統的 CMD 視窗，請輸入以下指令：

ssh -T -i “%USERPROFILE%.ssh\your-key_ed25519” git@github.com

當你按下 Enter 鍵執行之後，系統會連線到 GitHub 並回傳訊息，請根據畫面上顯示的文字來判斷結果：

如果畫面顯示 Hi 小帳的名字! 開頭的文字，代表這把金鑰已經正確設定在 小帳底下了。

如果畫面顯示 Hi max32002! 開頭的文字，代表這把金鑰目前被綁定到了錯誤的帳號。

目前系統檢查出來的結果依然顯示為 max32002 ，這代表你還需要去登入小帳的 GitHub 帳號，並將這把金鑰重新新增進去，才能正常使用。

實際執行上面句子, 會遇到錯誤因為

在 CMD 環境中，系統無法辨識以 $ 開頭的變數符號，因為那是 PowerShell 的專屬語法。如果在 CMD 裡使用，系統會找不到路徑。

請改用以下適合 CMD 的指令：

DOS

ssh -T -i "%USERPROFILE%\.ssh\your-key_ed25519" git@github.com

或是直接填入完整的絕對路徑：

DOS

ssh -T -i "C:\Users\max32\.ssh\your-key_ed25519" git@github.com

File: C:\Users\max32\.ssh\config

# Default GitHub account: max32002
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes

# GitHub account: max2little (use host alias: github-max2little)
Host github-max2little
    HostName github.com
    User git
    IdentityFile ~/.ssh/max2little_ed25519
    IdentitiesOnly yes

設定已經全部完成！以下是設定內容的摘要：

使用方法：未來在複製或設定 max2little 帳號的遠端儲存庫時，請將原本的 github.com 替換為 github-max2little。

範例指令如下：

Bash

git clone git@github-max2little:your-repo-name.git

預防帳號切換錯誤方法

max32002@example.com (小帳) 這個 email 被登記在 GitHub 的 max-little-account 帳號底下，所以即使 commit 不是 max-little-account 做的，GitHub 也會把該 author 連結到那個帳號的頭像。會發生即使是使用大帳進行 commit, 但是在history 上會看到是小帳進行 commit.

修正步驟（事後參考）

# 1. 設定這個 repo 的 git 身份
git config user.email "max32002@gmail.com"
git config user.name "Max"

# 2. 重寫最近 N 個 commit 的 author
git rebase HEAD~4 --exec "git commit --amend --reset-author --no-edit"

# 3. Force push（因為 commit hash 改變了）
git push origin main --force

預防方法

在這個 repo 目錄下執行一次，之後每個新 commit 都會用個人信箱：

git config user.email “max32002@gmail.com”

電腦的 global git config（~/.gitconfig）若設定的是公司信箱，建議也在每個私人 repo 單獨覆蓋，避免日後再出現同樣問題。