2011-04-13 107 views
1

我見過很多關於restful-authentication的問題,但我想知道在使用RESTful web服務進行身份驗證時,使用什麼策略來保持瀏覽器用戶代理無狀態。使用自定義REST客戶端做它很「容易」:我們可以使用基本身份驗證,摘要,OAuth或滾動您自己的(自定義標頭,令牌,簽名等)。因此,對於機器對機器而言,我們幾乎可以覆蓋,但我只對使用日常瀏覽器用戶代理(IE,Firefox等)進行身份驗證感興趣。例如JSON是掉,因爲瀏覽器無法渲染/使用它;)RESTful瀏覽器用戶代理和身份驗證

下面是我的一些想法在瀏覽器限制方面:

  • AFAICS沒有辦法的瀏覽器發送自定義標頭,如OAuth使用的標頭? (對吧?)
  • 我有一種感覺,應該可以有一個登錄頁面(例如html + ssl)用戶進行登錄。 (無基本驗證)然後,瀏覽器捕獲一個令牌並將其傳回服務器並提供每個請求。我使用基本身份驗證的問題是我沒有「很好的自定義登錄頁面」。當前的身份驗證機制是否可擴展,以便我們保持安靜?
  • 由於存在失去可伸縮性優勢的風險,我在打破/放寬REST約束時非常小心。

一個similar answer here但我對餅乾一個特殊情況:(而不去太多細節):瀏覽器目前使用的cookies的工作方式是不可能的,因爲服務器是在餅乾的控制。 (來自服務器端狀態的「Set-Cookie」頭部)。客戶不理解或解釋它所提供的cookies的內容,只是返回它。問題是客戶端無法控制Cookie。因此,我們可以在「自定義/機器到機器客戶端」中以平穩的方式使用cookie,但這不是瀏覽器實現它的方式。

您曾經使用過哪些策略和最佳實踐,以及您有什麼經驗?任何額外的評論?

+0

一些額外的信息:我使用定製的http服務器(Qt)。我對人們使用的方法感興趣,它對放鬆或堅持REST約束有什麼影響。他們做出的權衡以及影響的道路。 – 2011-04-13 22:32:21

回答

1

我認爲您提到的瀏覽器限制對於大多數使用情況來說基本上是不可逾越的。我們的個人解決方案是向用戶提供一個輕量級的非RESTful層,其中包含一個定製的REST客戶端;例如,對於JavaScript應用程序,我們通過JSON-RPC公開服務器端REST客戶端。

+0

我喜歡關於瀏覽器中客戶端的想法,因爲它符合按需代碼的REST原則。我可能會拋出一些jQuery身份驗證助手腳本。謝謝。 – 2011-04-14 09:37:50

1

如果您使用的是Apache Web服務器,您可能需要查看this document

+0

經過一些更多的研究,我重新發現了引用的鏈接。不錯.. +1。我使用我自己的C++ Web服務器,這種方法看起來很有趣... – 2012-08-27 20:06:48