随着近日 Spring Social 的发布,InfoQ 邀请到了该项目负责人 Craig Wall。首先,有请 Craig Wall 解释下是什么促成了 Spring Social 这个项目:
Craig Walls:目前有许多线上网站需要用户来维护他们的身份信息。一些社交网站如 Facebook 和 Twitter,为用户提供了联系友人及家人并在其间分享生活点滴的功能。就连某些被认为不具备“社交”功能的服务,如 Dropbox,现在都具备显示联系人在线状态的功能。
其中大多数服务都是以 REST API 的形式提供,应用创建后通过用户行为与多样化的服务相互作用,可以产生更多超越服务本身功能的体验。伴随着拥有超过 7 亿 5 千万用户的 Facebook、超过 2 亿用户的 Twitter,以及拥有类似用户数量的其他服务提供方,可以预见的是,具备社会化体验和在线体验的应用将拥有无限发展空间。
尽管如此,构建这类应用有时也充满了挑战。虽然 REST API 看上去很简单,但在使用其接口之前,仍需要取得访问用户资源的授权。一旦通过了授权,就会去想如何把这种长连接持久化,以至于不用每次在访问资源时都要再授权。当调用某个服务时,将响应与对象模型绑定,从而达到处理任何可发生事件的效果。
通过管理连接进程以及将 Java 与服务的 REST API 进行绑定,Spring Social 的出现大大简化了应用程序的开发。
InfoQ:您认为哪类应用适合与 Spring Social 的连接器集成?
Craig Walls:只要是需要与一个或多个服务提供方交互的这类应用,Spring Social 都可与其完美集成。同样也可以是一些简单的操作,比如从 Twitter 读取一条信息或向某个用户的 Facebook 照片墙上上传一张照片等。
此外,应用还可以做一些更加有趣的可以增强用户体验的事情。比如一个基于音乐流媒体应用,可以首先通过 Spring Social 获取用户 Facebook 上喜好的音乐家列表,然后以此来优化该用户的播放列表。类似的应用还有通过获取用户的旅游日程,然后向用户推送当地的音乐会或音乐活动等信息。
这种方式的魅力在于,一旦用户得取得访问应用数据的授权,通过将无限的创造力与些数据的集成,可以带来全新的用户体验。
InfoQ:我们都知道 Spring Social 与 OAuth 联系紧密。这是否要求与 Spring Social 结合的服务提供方都要基于 OAuth 授权呢?
Craig Walls:Spring Social 的 1.0.0 版本提供了对可加密用户资源的 OAuth 的直接连接支持;无论是 OAuth 1.0、OAuth 1.0a 还是 OAuth 2。已经将大部分的实现 OAuth 的服务提供方包含了进来,其中不乏一些耳熟能详的提供方:如 Twitter、Facebook、TripIt、GitHub、Foursquare 和 Gowalla 等。
换句话说,Spring Social 的连接框架是可扩展的。除此之外,Spring Social 还可通过扩展实现对其它类型授权服务的支持。
InfoQ:OAuth 1.0 与 OAuth 1.0a 有着怎样的区别?
Craig Walls:OAuth 1.0 存在一个安全漏洞,该漏洞允许攻击者通过开启连接进程获取请求标识,然后利用该标识欺骗被攻击者从而获取用户授权,最终攻击者获得对用户资源的访问权。该漏洞已经在 OAuth 1.0a 中被修复。
但不幸的是,仍然有一些服务提供方还在部署 OAuth 1.0。同时,他们中的大多数已经考虑弃用 OAuth 1.0 转而投向 OAuth 2,同时他们也相信在很短的获取请求标识(通常只有几分钟)周期内,很难实施这样的攻击。也有一些服务提供方在各自的 OAuth 1.0 实现中增加了额外的约束(例如限制返回的 URL 必须同预注册中返回的 URL 相一致),以此来减轻遭受攻击的风险。也有些服务提供方提醒用户只接受可信应用的授权请求,以此来减少被攻击的风险。
为了支持 OAuth 1.0,Spring Social 依然保持着与这些服务提供方的连通性,其中有著名的 Triplt 和 Dropbox 等。但当部署需要连接 OAuth 1.0 服务的应用时,仍需保持警惕。
InfoQ:Twitter(或是其他)的服务提供方所需用到的密钥需要通过加密的方式保存到数据库中,Spring Social 对此是否提供了支持?
Craig Walls:当然!授权给应用的标识和密钥,在访问用户资源时都会用到,这些都需要防止被窥探到。因此,在配置 Spring Social 连接库时,必须为连接库选择加密机,该加密机将在传输标识和密钥时启动。加密机可通过实现 Spring Security 的 TextEncryptor 接口的方式实现。在我们提供的示例应用中,采用了不带有任何操作的文本加密机,以此来简化 Spring Social 初学者的学习曲线,但对于上线的应用来说,使用健壮的加密机还是很有必要的。
InfoQ:最后,基于 OAuth 的原理以及浏览器的三条腿认证的特性,您是否认为 Spring Social 主要适用于基于用户浏览器的基于 Web 的系统,对于无头系统(Headless System,在无鼠标、键盘和显示器环境下工作的系统)Spring Social 是否也适用呢?
Craig Walls: Spring Social 1.0.0 提供了对用户操作过程中使用到的 OAuth 1 和 OAuth 2 的支持。这也就是通常意义上的三条腿 OAuth 1 和 OAuth 2 认证流程。这都需要通过用户浏览器来重定向到服务提供者进行授权。
但这并不意味着使用 Spring Social 的应用一定要是基于 Web 的。以 Android 应用为例,显然不是一个 Web 应用,但同样可以使用 Spring Social 来连接服务提供方。这时,在需要授权时只需调用 Android 设备中的浏览器即可,应用中的其余部分完全可以是基于本地化开发的。
至于无头系统,还可选择其他的无需用户参与的授权策略,例如两条腿 OAuth 1 或者是 OAuth 2 的用户名密码模式(Resource Owner Password Credentials),也有客户端验证的方式可供使用。Spring Social 的 1.0.0 版本中尚未提供对以上认证策略的支持,但是已经考虑在未来的发布中增加进去。
更多信息可访问 Spring Social 首页,其中列出了可用的其他连接器。尽管 1.0 版本中包含了 Facebook 和 Twitter 连接器,其他连接器(例如 GitHub、Triplt 和 Linked In 等)以及其他社区的类似于 Foursquare 和 Instagram 的连接器仍处于开发阶段。任何关于 Spring Social 的问题,都欢迎在下方的评论中留言。
评论