2010-05-20 60 views
6

我正在開發一個Web服務,我需要在GET方法中向服務發送用戶名和密碼。只要它通過像ssl這樣的安全通道就可以在uri中發送這些信息嗎?換句話說,我可以擁有一個看起來像/ users/{username}/{cleartext_password}的uri嗎?發送用戶名和密碼到Web服務

編輯:對不起,我想我不清楚。 Web服務本質上只是用戶名和散列密碼的數據庫。想象一下,將用戶名和密碼保存在遠程數據庫中的桌面應用程序。最終用戶將他們的用戶名和密碼輸入到應用程序中,然後應用程序訪問Web服務以對用戶進行身份驗證。

因此,應用程序需要向服務發送最終用戶的用戶名和明文密碼。該服務將獲取用戶名和密碼,並檢查用戶名和密碼的散列與數據庫中的用戶名和散列密碼相匹配。應用程序本身在訪問服務之前必須進行身份驗證,但我只是想知道將最終用戶的用戶名和密碼發送到服務以驗證最終用戶的最佳方式。我不使用POST方法,因爲我只是進行身份驗證,因此不會更改服務器的狀態。對困惑感到抱歉。

回答

0

一般來說,這不是一個好主意......這些數據將出現在多個日誌文件中,因此數據可能會被不應該看到的人看到。如果可以的話,至少應該在發送之前對其進行散列或加密。

這裏是一個小更詳細的相關討論... Is an HTTPS query string secure?

+0

或者你可以看看做雙向SSL認證。用戶需要使用與服務器相同的證書,但服務器可以安全地對用戶進行身份驗證。 – mpez0 2010-05-20 18:57:15

0

如果它要通過安全通道,有作爲發送明文用戶名和密碼沒有問題。我只是建議不要將它們作爲明文通過不安全的通道發送,並針對每個請求反覆發送它們。

你可以做的是首先對Web服務進行身份驗證(通過SSL發送用戶名和密碼作爲明文),並從服務器獲取它將識別的令牌。然後發送該標記與每個後續請求。

+0

例如,Google允許您通過SSL發送您的用戶名和密碼以檢索其API的SID ...然後您將該SID發送到每個後續GET請求的cookie中。它工作得很好。 – EAMann 2010-05-20 18:48:28

7

做到這一點。

發送「密鑰」和「摘要」。

「鍵」相當於一個用戶名。

「摘要」是密鑰,URI和「共享密鑰」或密碼的SHA1(或MD5)散列。

當服務器得到它時,它根據請求的密鑰URI和「共享密鑰」或密碼計算出它自己的摘要版本。未能匹配摘要是401錯誤響應。

+0

這實際上是一個非常優雅的解決方案... – EAMann 2010-05-20 18:56:11

0

SSL確實會對URI進行加密,但絕對要看看一些替代方法。

HTTP基本驗證是好的,簡單,和由瀏覽器,Web服務器以及支持等

它還在日誌文件中會不會落得相同的程度的URI

注意:這只是一些純文本的HTTP頭,所以非常不推薦用於非SSL應用。

http://en.wikipedia.org/wiki/Basic_access_authentication

相關問題