2009-08-30 62 views
3

我想知道是否有可能做一個RedirectToProvider,並讓生成的OpenID提供者頁面顯示在一個iFrame中。這將使認證流程看起來更加精簡。iFrame中的DotNetOpenID

我在ASP.NET MVC(VB)中使用DotNetOpenID庫。

接下來的部分是一個單獨的問題,但是是相關的。

我使用Ajax.BeginForm作爲OpenID登錄窗體,但是RedirectToProvider由於某種原因而失敗。 DotNetOpenId不適用於MVC和AJAX嗎?

+0

是不是Dot * Net * OpenID而不是Dot * Not * OpenID;) – JohannesH 2009-08-31 01:04:29

+1

哈哈,取決於它是否有效! – j82374823749 2009-08-31 17:53:40

回答

3

是的,DotNetOpenId支持iframe,MVC和Ajax。與庫一起提供的OpenIdAjaxTextBox控件將顯示在其中一個示例中。它不使用iframe來顯示什麼。它將它們與checkid_immediate一起使用,以在沒有任何用戶交互的情況下嘗試隱式登錄,這是OpenID意圖支持的唯一iframe場景。

IAuthenticationRequest.RedirectToProvider方法在內部調用ASP.NET Response.Redirect,這本身就拋出一個ThreadAbortException,這可能是爲什麼它似乎是失敗的你,而事實上,它可能是由設計工作,而是設計衝突與你」可能試着去做。

有很多方法可以完成你想做的事情,但是正如Alex Alex建議的那樣,在iframe中託管Provider的頁面時存在一個安全問題。這並不是說RP可以訪問或使用iframe的內容,因爲正如EFraim所說,除非瀏覽器存在不允許的錯誤。這兩個問題是Clickjacking,並且您正在訓練用戶被釣魚,因爲他可能會在RP的URL位於地址欄時向他的OP提供其登錄憑據,這是一件壞事。

而事實上,現在主要的OPs在iframe中被激活時故意拒絕工作,因此在完成所有工作以達到您想要的方式之後,您可能會對大多數客戶獲勝感到失望無法登錄。另外,正如你指出的那樣,彈出窗口,如果正確完成,可以幫助保持體驗用戶友好。 DotNetOpenId也可以通過幾種不同的方式實現。庫附帶的ASP.NET控件具有內置的此功能,只需在控件上設置屬性即可激活。但是,由於您使用ASP.NET MVC(我認爲),這裏就是你可以自己做:

  1. 當用戶點擊頁面上的登錄按鈕,而不是發佈到當前窗口,有用Javascript打開適當大小的彈出窗口,如http://yoursite.com/openid/redirect?id=userSuppliedIdentifier

  2. 您的OpenID控制器的重定向操作將讀取該ID,對該ID執行OpenIdRelyingParty.CreateRequest,並對return IAuthenticationRequest.RedirectingResponse.AsActionResult()(MVC樣式)執行該操作。請注意,如果您希望OP的回覆回到您的OpenID控制器上的其他方法,您可以將自己的URL傳遞給CreateRequest以獲得returnTo url。

  3. 當斷言返回時,您的控制器應發送關閉彈出窗口的javascript,並(根據需要)返回主窗口以更新其登錄用戶的狀態。

整個過程在DotNetOpenId附帶的ASP.NET控件中完全自動化。不幸的是,ASP.NET MVC不能像ASP.NET Web窗體那樣模塊化,所以你不必自己做所有這些工作。當然,DotNetOpenId附帶的MVC示例可以顯示如何在未來的版本中執行彈出行爲。如果你想要的話,file a wish for it

+0

問題是,你永遠不能依靠用戶自己來警惕安全。對於所有人口中的99.9%來說,安全性是一件令人討厭的事情,我們不想甚至不打擾。但它仍然需要。 – 2009-08-31 07:28:19

+0

瀏覽器本身的安全性取決於可能會濫用某些漏洞的自定義客戶端代碼。這可能是一些JavaScript黑客攻擊,也可能是Flash黑客攻擊。現在我們也有Silverlight,它也可以添加更多的方法來破解IFrame。 OpenID提供商應該非常小心這些風險,儘管它有很多合法的用途。但是像MS,Google和Yahoo這樣的提供商是這種身份盜用計劃的主要目標,因此他們往往偏執於健康的方式。 – 2009-08-31 07:31:29

+0

謝謝安德魯,第二(在SO)內容豐富且有用的帖子,你幫助過我!現在,我想我會堅持重定向用戶。有很多可以出錯! – j82374823749 2009-08-31 17:59:19

2

問題是,OpenID提供商是否認爲這是安全風險?如果提供者頁面位於IFrame內部,則周圍的頁面可以控制該框架內發生的情況,包括嘗試捕獲某些信息。這可能是一個可能的漏洞風險。請記住,OpenID提供商對這些事情非常偏執,甚至可能試圖從這樣的IFrame中跳出來,或者只是拒絕任何進一步的登錄操作。這是他們可能不想採取的風險。 這可能嗎?如果是這樣,我認爲答案也取決於提供者。

+1

我從來沒有真正想過它的安全性方面!我認爲爲什麼我看到的所有RP都沒有使用過iFrame,這一定是有原因的。但是,我看到彈出窗口使用。這是否也爲提供者呈現了一種可調性? – j82374823749 2009-08-30 13:59:23

+0

IFrame與所有其他內容具有相同的來源策略。只要瀏覽器沒有相關的錯誤,一切都很好。 – EFraim 2009-08-30 14:57:03

+0

彈出窗口也可能存在安全風險,但它會在它自己的瀏覽器窗口中運行。使用頁面周圍的IFrame時,主頁有可能監視用戶操作的JavaScript或其他可執行代碼處於活動狀態。當彈出窗口在單獨的窗口中時,這樣的事情很難做到。 – 2009-08-31 07:23:42