基本上有兩種方式可以實現用戶驗證通過HTTP使用的平臺:
- 「經典」的基本HTTP認證(請參閱確切的規格RFC2616),
- 登錄表單,創建會話ID並將其返回給瀏覽器,以存儲在cookie中或URL中。
基本HTTP身份驗證通過在您的網頁服務例程中插入支票來查看是否存在授權HTTP標頭。如果有,請解碼(請參閱RFC),並檢查指定的用戶名/密碼。如果憑證正常,請繼續進行網頁服務。如果憑證不正確,或者沒有授權標頭,則應返回401錯誤代碼。瀏覽器然後會提示用戶輸入憑據。這個解決方案非常簡單,你會得到瀏覽器登錄對話框,而不是一個很好的HTML頁面。另外,微控制器必須檢查每個頁面請求的憑證。
通過登錄表單進行身份驗證的工作方式是由服務器維護經過適當身份驗證的用戶會話(可能位於內存中)的列表,然後根據此列表檢查請求。登錄後,應爲該會話生成一個唯一的隨機ID,並將會話數據輸入到您的列表中。新的會話ID應該返回給瀏覽器以包含在即將到來的HTTP請求中。您可以選擇將會話ID放入瀏覽器cookie中,或者將其嵌入到URL中,作爲URL參數(?id = xxxxx)。通過使用新URL向瀏覽器發送302重定向響應來嵌入URL參數。如果您需要cookie解決方案,您可以使用Set-Cookie HTTP響應標頭將響應發送到登錄請求。在登錄表單解決方案中,實際憑據(用戶名/密碼)僅在登錄時檢查一次。之後,只會根據活動會話列表檢查會話ID。會話ID必須從每個網頁服務的請求中提取(從URL或Cookie HTTP頭中提取)。此外,您必須實施某種會話超時,這既是一種安全措施,也是爲了限制活動會話列表的大小。
現在變得更加困難:在這兩種解決方案中,用戶名/密碼都會在一些請求中傳送(每次請求進行基本HTTP身份驗證,登錄頁面POST進行登錄表單解決方案),並且可以從網絡流量。此外,兩個解決方案中的每個請求都存在需要劫持會話的信息。如果這是一個問題(系統在可自由訪問的LAN網段上工作,或通過超出您控制範圍的網絡鏈接工作),您可能需要使用SSL來隱藏這些敏感數據。如何爲您的平臺獲得合理的SSL實現,這是另一個問題。