Fishbone REV20110208

 

http://www.mewchew.com/fishbone/

这是什么？
fishbone是twitter的API代理。帮助你在墙内方便地使用twitter。任何问题请@alzzl或者alzzl@hotmail.com

如何使用？
首先你需要在翻墙状态下点击本页上方的连接。授予fishbone访问你twitter帐户的权限。一旦授权成功，fishbone会将你的api地址告诉你。

当你使用支持自定义API的twitter客户端时，填入你的api地址就可以使你在墙内访问你的twitter账户。

哪些客户端支持自定义API？
PC端：TweetDeck、Spaz、Chromed Brid
Android端：twigee、Seesmic

完整设置步骤：
1.获取API地址（需要翻墙）
点击本页面顶部的连接。

点击Allow让fishbone获取你帐户的读取和写入权限。

 

记下这个api地址。如果丢失可以通过上述步骤重新申请一个新地址。

2.设置客户端

spaz

填写你的用户名，密码不用填，type选custom，在下面的Base API URL中填入刚才获取的api地址，保存后就可以正常使用了。

Fishbone Rev20110116(twitter API Proxy)

最近正在写的东西，目前只支持经典模式的自定义api（自己起的名字）。

现在可用的twitter API Proxy 都是PHP下的，于是就用c#写了个，感谢@yegle的指点。

现在的版本仅仅完成了转发部分，因此客户端必须支持自定义签名url，或者签名url固定为官方地址。

windows下满足这个要求的客户端只有chrome的插件chromed brid。

让chromed brid用官方的地址进入签名的计算。第一次使用时需要翻墙以便chromed brid获取你的twitter token。

这个模式下fishbone直接转发你的数据，所以是chromed bird请求你的访问权限。

如果仅仅是浏览的话可以通过 mewchew.com/fishbone/+用户名 来浏览。
http://mewchew.com/fishbone/alzzl

OAuth学习作业：Mewdam

最近看了些OAuth的资料，于是有了想应用一下的想法，再于是就有了这个程序。

不会php，所以这个东西是用c#写的，目前完成了OAuth验证部分，twitter API只做了home_timeline

OAuth的认证过程很简单，除了计算signture部分，顺便分享个OAuth调试网站，他可以对认证的错误原因进行详细的说明http://term.ie/oauth/example/

http://www.mewchew.com/mewdam/

第一次使用需要通过OAuth验证，验证过程需要翻墙。

给mewdam授权，让其获取对你twitter的访问权限

Introduction – The Authoritative Guide to OAuth 1.0

翻译自http://hueniverse.com/oauth/guide/
这是介绍OAuth的文档，状态是还在编写中，但是更新日期停滞在了09年，这是其中的第一篇Introduction。

网站的备用钥匙

许多高档汽车都配有备用钥匙。这是一种为司机提供的特殊的钥匙，用它发动后，车辆只能行驶一小段距离，并且无法打开后备箱也无法使用车载电话。使钥匙的功能有所限制是个非常棒的主意。你对自己的汽车拥有完全的控制权，而其他人只能使用其部分的功能。

互联网高速的发展，随着越来越多的站点开始使用分布式服务和云计算：照相馆直接打印你储存在Flickr中的照片，社交网站通过你的Google联系人寻找你的好友，或者第三方的程序通过API使用各种服务。

为了访问你的个人数据，这些站点会向你索取账号名和密码。这样就产生了一个问题，你的密码可能会因此泄露，并且一般情况下你不会为每个站点设置不同的密码，在某种意义下，这个站点便会获得你其他站点中的使用权限，甚至银行账户。

OAuth提供了一个可以让第三方在获取用户数据的同时，保证他们的密码不被泄露的方法。此外，它还可以对授予的权限进行控制（如操作的范围、时长等等）。

例如：用户（资源所有者）可以不用提供帐户密码就授予打印服务商（客户）访问其存储在照片分享站点（服务商）中的私人照片的权限。换句话说，用户向客户提供了服务商的指定委托认证。

改进服务端/客户端模型

在传统的客户端-服务器认证模型下，客户使用自己的凭据来访问服务器中的资源。OAuth在这个模型中引入了第三种角色：资源所有者。在OAuth模型中，客户（不是资源所有者，但是可以代表这个角色）向资源所有者请求获取存储在服务端中资源的控制权。

客户为了访问资源，他首先需要获取资源所有者的许可。许可的形式是经过共享密钥加密后的令牌。令牌的作用是使资源所有者不用再向客户提供他的凭据。与凭据不同，令牌可以限制其适用范围、生命周期并且可以单独地销毁。

发展过程

受Microformats团队的启发，OAuth决定从现有的成功案例中构建其第一个版本的协议。为此OAuth向诸如Google AuthSub, Yahoo BBAuth, and Flickr API中吸取了诸多经验。

每种认证协议都提供了不同的方法用于将用户凭据转换成令牌。OAuth在设计时十分小心地研究了这些协议，并且同作者交流，提炼出最好的对策为新的实现提供支持，以便它们在对OAuth的支持过程中实现平滑过渡。

同部分协议和服务相比，OAuth显得更为先进，因为他可以直接对非站点的服务进行操作。OAuth内置了对桌面程序、移动设备、机顶盒、网站的支持。