2011-07-06 43 views
1

我正在使用使用OAuth的appengine應用程序。當然,我正在同時處理多個版本的應用程序 - 本地版本的開發,暫存版本和部署版本。具有單個應用程序的多個使用者密鑰的OAuth提供程序

要處理這些問題,我需要三組獨立的OAuth使用者密鑰/密碼,因爲身份驗證的回調是在提供商的網站上定義的。

我想知道提供者是否有辦法爲給定的應用程序提供多個鍵/祕密 - 這似乎比每次設置新應用程序更有意義。 (當然,它要求提供者實現這一點,但這似乎是一個自然而然的事情,我沒有看到它)。

更一般地說,使用什麼標準方法來處理這個問題 - 我的猜測是註冊多個應用程序,並在應用程序中有邏輯來確定它是否處於開發模式,暫存或部署。任何想法歡迎。

回答

5

我覺得這是成爲OAuth API客戶端開發人員最煩人的部分之一。沒有理由提供商不應允許開發人員註冊重定向(回調)URI進行測試。

我見過的標準方法是允許您將一個或多個域名列入白名單以進行回撥/重定向。 Facebook有一些瘋狂的設置,他們讓你「註冊」多個域,爲應用程序配置文件中的各個鏈接使用不同的域。我沒有太多運氣。 Twitter是更好的實現之一,讓你註冊多個域名。

在OAuth 2.0(草案18或更新版本)中,該主題得到更好的處理。建議您完整註冊URI,並註冊多個回調,並在請求時動態選擇您想要的回調。

要考慮的主要方面是如何處理使用臨時安裝程序的權限?你希望能夠重新使用現有的批准,還是希望保持這些獨立?此外,如果API提供特殊的僅客戶端調用(例如客戶端存儲或管理工具),您是希望階段版本共享它還是保留它自己的(以便測試不會混淆生產)。

最後,提供商應該提供一個完整的開發環境,包括API客戶端的測試工具。大多數不。

+0

感謝您的深刻反應(我還沒有足夠的代表upvote) - 很高興看到我不是唯一一個看到問題的人。 關於處理權限的問題 - 我想一個解決方案是完全解除對應用程序的不同變體的批准,這很好 - 看起來像是今天解決方案的自然演變。 –

0

從API提供者的角度來看,您的應用只是一個使用API​​的應用。通常不存在「暫存」API,它不處理實時生產數據。無論你在測試什麼,你是在實時數據上測試它嗎?

如果你能夠註冊幾個不同的應用程序,例如不同的回調,那麼我認爲你的問題已經解決了。我的觀點是,消費者有責任將這些事情分開。

相關問題