随着近日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 的问题，都欢迎在下方的评论中留言。
注册/登录 InfoQ 发表评论