我意識到這個問題上有很多問題,我一直在研究這個問題幾天。我想確保我的問題儘可能具體,因爲我尚未充分理解最佳方法。Web客戶端和移動REST API安全性的推薦配置
目前我有一個開發的Django站點,與web客戶端通過django活塞json REST API進行大概95%的通信。其他5%是一些重新登錄功能,仍然通過POST表單與CSRF保護。理想情況下,我想將其餘部分移入REST API。
我現在需要找出最佳推薦解決方案,以保護Web客戶端和移動客戶端(應用程序尚待開發)的可重用和快樂共存的方式。我已經閱讀了許多帖子,最終爲移動端推薦了OAuth2(和https),但我仍然對如何設置Web客戶端安全性感到困惑。我也在瞭解OAuth2方面,以及我是否可以使用雙腿形式。就目前來看,Web客戶端是django認證的。從技術上講,jsonp功能在活塞中仍然很活躍,所以我認爲只要他們的Web會話具有auth cookie,任何人都可以使用來自第三方應用程序的api?
總結我的API的用法:
- 的API是一個完全私有接口的服務器應用程序
- 這將是理想的,如果API無法得到廣泛的第三方網絡重用客戶混搭。
- 該數據不是necc敏感。它只是一個社交型網站最個人信息是基本的用戶配置文件的東西像電子郵件,地址等我的問題
摘要:
- 的OAuth2是最好的推薦方法保護移動應用程序訪問權限?它與Web客戶端方面有什麼關係?如果推薦使用OAuth2,它是否應該是與應用版本一起版本化的應用範圍內的密鑰?
- Web客戶端應該使用通過ajax傳遞的CSRF,並且只需禁用jsonp以確保其始終相同的原點?基本上,我是否分開處理Web客戶端安全?
- 我應該如何組織網址/應用程序實例/子域名或建議使用哪種方式來維護網絡與移動安全?我只需要單獨的網址前綴,一個用於使用不同規則的移動設備?
我在尋找django-piston的具體建議來解決這些問題。我已支我的項目,並開始與活塞的這個分叉版本玩:https://bitbucket.org/jespern/django-piston-oauth2
我有一個想法是創建一個活塞的資源,首先檢查它的同源,然後只強制Django的權威性,否則強制oauth2,但我不確定這是否合適。
更新1/1/2012
從尖峯提供的信息,我開始與活塞的oauth2工作。我結束了創建的一個叉子增加對nonrel的Django(MongoDB的)一些修復和我分叉某人的例子也使用的oauth2和活塞:
https://bitbucket.org/justinfx/django-piston-oauth2-nonrel-example
現在,它只是我真的掛鉤這件事的問題到我自己的項目並讓它工作。但是這些測試都很好。
現在_this_是寫得很好的問題!很高興看到有人嘗試。 – Polynomial 2012-01-28 22:15:19
謝謝!我真的不想問一個問題,如果我知道它不是很詳細,並被問到以前相同的方式。我在這裏看到太多的人只是隨便丟下2句話,並要求所有人解決問題:-) – jdi 2012-01-28 22:18:17