
OAuth以降, 第三方client需要在授权时接触明文密码的问题解决了. Twitter在今年8月开始强制推行OAuth授权方式. 对此, R中的twitteR包作者Jeff Gentry却在最新的文档中叫苦不迭:
The old Twitter authentication mechanism is being removed in August 2010 in favor of OAuth. As of this writing there is not an OAuth solution for R, so unless someone (or myself) writes such a beast you will not be able to access any authenticated aspects of Twitter. Many functions that you might be familiar with using will no longer work properly, if at all. These have been set to be defunct.
Also not that it is not simply a matter of having an OAuth interface, but also that Twitter's usage of OAuth is very tied to having stable applications as opposed to scripts being written. There are currently various potential workarounds for this that I'm looking into.
看来自从授权方式改为OAuth之后, 大部分写好的功能都极其华丽丽的失效了. 我没有读过OAuth规范, 不过个人认为, 实现OAuth的一个难点在于需要用户在浏览器中进行一步通过授权的操作. 而其他的token生成, 取回token之类的, 对于开发者都是些简单问题而已. Stack Overflow上就曾经有人问在R中怎么进行OAuth授权的问题, 有人说不妨尝试用Quick and Dirty的方式, 其实, 这个答案也很Quick and Dirty啊.
从这个角度出发, 就我的感觉, 从技术上讲, client开发大概可以分为以下3种情况:
- Web开发, 如php. 客户端本身就是在浏览器里干活, 很容易实现, 且可以借鉴现成代码;
- 编译型语言的桌面开发, 如C. 可以通过在客户端内调用浏览器组件实现认证, 对用户很友好, 且有现成的lib, 实现较容易;
- 脚本语言的桌面开发, 如Python和R. 除非写很suck的GUI client, 否则基本不可能在客户端内调用浏览器. 这时就可以分出两种处理方式:
- 打开(或让用户手动打开)浏览器, 然后授权获取token, 让用户手动粘贴过来, 整个过称很怪异, 很不友好;
- 祭出神器cURL(libcurl)处理.
这里忽略情况1和情况2, 专注于情况3. 情况3的第一种处理方式非常不友好, 但是这也是一些现有示例的处理方式, 如Python. -_-!! 而第二种处理方式的技术难度非常高, 因为天知道那个授权页面是不是用了一些cURL容易处理的方式写成的, 比如授权页面里包含了一些ajax或是其他的什么东西, 完全依赖于开放API的网站有没有考虑到这一点了. 当然, 这是我的个人看法, 这些问题对于大牛也许都不是问题吧. 当然, 如果能使用第二种处理方式, 是再好不过了, 简直完全不亚于情况2. 不过我想没有真正的最终用户去用这种纯命令行的client, 基本都是开发人员用. 以上那些所谓的友好不友好的标准, 也都是针对会用哪一种client做事的用户群而言的, 莫要细究.
回到开始的TwitteR话题. 一位日本人在最近写了一些关于在R中怎么进行OAuth授权的东西, 当然, 仅仅是针对Twitter的. 他的Slides在这里可以看到. 相关的R代码在GitHub上. 由于我没有研究过这个网站的API, 所以不知道他最后实现的是不是我所谓的第2种方式, 单纯从代码上看起来还是比较像的. 希望Jeff看到这些能够有动力把包里的大部分函数更新一下 ...
同时也期待Duncan Temple Lang这些牛人们早日给R做一个标准的OAuth包吧.