本篇內容來自於文獻：The human element: "The User Experience"

前篇說到了爲用戶 troubleshoot 而開發的入口網站，今天我們繼續看該如何進入該入口，以及它會做什麼事。

從錯訊頁面進入

開發完了該入口網站後，我們便將其與 Access Proxy 回傳給用戶的錯誤消息集成在一起，讓用戶可以從 Access Proxy 回傳的錯訊中被導入（如下圖）。在回傳錯訊的同時我們已自動轉發了所有相關的錯誤信息給該入口網站。當用戶點擊按鈕時，入口網會重新發送訪問請求到後端，並精確解釋問題的原因。

圖 1. Access Proxy 回傳的錯訊中包含入口網站的連結 (source: The human element: "The User Experience")

舉例來說，如果某個資源需要特定群組的成員才能訪問，入口網站會提供該群組的名稱和一個連結，讓用戶可以請求加入該群組。

入口網站怎麼知道是因爲群組權限問題所以訪問遭拒呢？在這背後，入口網站會查詢後端 ACL 服務，以確定所討論的資源的授權要求，並將這些信息與用戶的身份進行比較。然後，前端將比較的結果轉化為人類可理解的陳述（如下圖)。所有這些都在幾秒鐘內完成，遠遠快於用戶自行解決組成員問題或尋求幫助所需的時間。

圖 2. 入口網站呈現的錯訊解釋 (source: The human element: "The User Experience")

臨時故障排除

除了從 Access Proxy 回傳的錯誤訊息中可以進入入口網站，我們還提供一個直接的入口網站界面以處理更多特殊問題。這個直接的入口網站界面，其前端的登陸頁面是根據訪問用戶和設備的身份定制的。它會提供用戶及其所有設備的信息，並突出顯示可能導致訪問遭拒的問題。

通過允許最終用戶主動訪問該入口網站，用於全面了解他們的所有設備和未來可能出現的訪問問題，我們讓他們能夠一舉解決他們所有設備的問題。這一功能對於在出差或演示前檢查設備信任度尤為方便。

Empowering 技術支援團隊

該前端還通過提供可立即執行的步驟，使我們的技術支援團隊能夠快速執行詳細的故障排除，從而大大縮短解決問題的時間。例如，為了解釋 403 錯誤頁面，技術人員可以使用門戶登陸頁面查詢特定的用戶名或設備標識符。他們可以深入到特定設備，確定其是否是完全受信任的企業設備。如果不是，支援團隊會給出設備不受信任的確切原因以及解決辦法（如下圖）。

圖 3. 從獨立入口網站進入可以看到設備信息 (source: The human element: "The User Experience")

好啦~~這就是今天的內容。不知不覺就看完了一篇誒！剩下兩篇了，加油！
今天沒有和夥伴一起爬樓梯，因爲太忙了，殘念。。。等假期放完一定要爬😤

明天我們開始學習第 6 篇文獻：Secure your endpoints: "Building a Healthy Fleet"。該篇著於 2018 年秋天，和今天學習的這篇 The human element: "The User Experience"相隔一年。

該篇內容基於前五篇文獻和白皮書 fleet management at scale: how Google manages a quarter million computers securely and efficiently，主要是在探討之前沒有討論過的問題：信任設備的機制，以及如何大規模管理受信任的設備。

有木有很期待！！我很期待😙

明天見~~