OAuth Case Study - 从Ning获取Flickr的Photos

一:登录Ning后，到Photo模块，点击Add Photos From Flickr

 

二：由于还没有对OAuth进行设置，于是Ning提示需要进行设置，点击后继续 

 

三：到了设置界面，Ning教我们如何进行设置，如果已经有Key和Secret，可以跳过前面几步，直接去后面填Key和Secret 

 

四：这个步骤是Ning给我们提供的oauth_callback，这个callback是后面在Flickr设置API时需要填的 

 

五：因为还没有secret和Key，所以我们到Flickr这边获取一个，登录略= = 

 

 

六，点申请Key后，弹出应用程序介绍。随便填填。

 

七：得到了API和Secret，回到Ning填到相应位置即可 

 

八：编辑应用程序认证流程，在回呼URL中填入Ning之前提供给我们的Callback URL
 

九：保存Ning的OAuth设置后，再次点击add photo这时弹出认证和授权提示：大概就是没登录的登录一下，登录后就能授权。
 

十：如果登录完成，就能进行授权，此授权时一次性的，Flicker会记住，如果以后不想对API授权了，可以去API管理界面移除授权 

 

十一：授权后则可以获取照片了
 

 

 

十二：此页面可以对API进行移除授权操作，如果移除授权了，下次从Ning再取照片，则需要再次授权 

 

 

小结:

①误解：我开始以为授权一次性完成后，可能就算2-legged OAuth了吧，但是换了台机器试了一下，身份认证是免不了的，所以不是。

②优点：Flicker对授权的管理值得学习，第一次授权后不需要反复授权，对于自己机器来说，cookie一直留着也不需要反复登录flicker，再次导入照片则完全无痛，一键完成。如果要移除授权，则进授权界面移除即可。

③疑问：授权管理是方便，但是对于普通用户来说，谁会了解其中细节？其实这一次授权可能大部分情况成了永久授权。

④Do evil：OAuth是用来取私密数据的协议，所以，通过认证授权后，Ning想Do evil很容易的，但是这个问题似乎永远是那个敏感又那么被人一直忽视着，就像讨论SaaS和云计算是否可行一样。当然对于google， ning或者salesforce等掌握大量私密数据的公司来说，他们也应该是不越作恶雷池一步的，因为信誉是这类公司的生命线。