用url發送憑據，可能嗎？

Question

我得到了一個我使用基本身份驗證保護並使用SSL的Web服務。爲了讓使用這個Web服務的客戶端變得容易，我想跳過401並使用url發送憑證（我希望客戶可以通過他們的代碼/ Web應用程序中的URL訪問Web服務），問題這可能嗎？

我知道關於標題，但很多客戶端使用這沒有得到適當的開發團隊做代碼。

謝謝

Answer 1

那麼，你當然可以，但你真的不應該。在URL中以純文本形式發送信息是不好的，因爲該URL可能會被緩存在幾個不同的地方，並且通常不必要地暴露敏感信息。你可以在發送之前加密它，但這可能比它的價值更麻煩。

使用純粹基於URL的認證的可接受方法是某種類型的標誌。您需要通過標準登錄過程來生成令牌。 附錄：另請注意，這比將純文本密碼放入URL中更好，但仍然存在問題。與其他標題信息相比，URL被更廣泛地記錄，緩存和書籤。至少你保留了令牌的控制權，並且可以在一段時間後過期，但URL中的密碼不能簡單地過期。

如果你正在開發一個API，我認爲這是足夠合理的，需要一些認證程序。如果你的客戶無法做到，請提供一個庫或代碼片段來幫助他們。

Answer 2

我完全同意@deceze。在URL中發送密碼很糟糕，完全破壞了擁有SSL的目的。另一方面，如果您使用BASIC + SSL，則您的身體會被加密。這意味着您的POST密碼（使用FORM - >用戶名&密碼字段）由於SSL處於操作狀態而不能被任何人解密。

我也不完全認同基於URL的auth與某個令牌是好的，主要是因爲不管你是否加密它（或不是！），該URL反正經過所有的躍點作爲查詢字符串給每個人。因此，任何人都可以閱讀URL並模仿。

HTH， 拉胡爾

Answer 3

警告：正如其他人所說，這是一個非常糟糕的主意！

但是，爲了回答您的原始問題，假設您正在使用基本身份驗證，您可以在URL中嵌入用戶名和密碼，如下所示。

http://userid:password@www.anywhere.com/

這將使它更容易爲用戶使用的API，併爲黑客繞過您的安全。你只比完全關閉認證稍微好一些。

警告：正如其他人所說，這是一個非常糟糕的想法！