Please Call Me Boss!

使用xmpp帐号绑定新浪微博gtalk机器人

众所周知，新浪微博提供了一个gtalk聊天机器人，由于gtalk是采用XMPP标准的，所以这个gtalk机器人也就天然地兼容了所有的xmpp帐号,这个gtalk聊天机器人目前有以下功能:

• 通过xmpp客户端向微博机器人发送消息来发表微博

测试通过,直接手工发送内容即可

• 通过xmpp客户端向微博机器人发送消息来评论我关注人的微博

测试通过,收到新微博的时候，微博机器人会提示如何发评论，需要使用相应指令

• 微博机器人自动同步我的xmpp客户端的签名到微博上

测试通过，不需要任何人工干预

• 微博机器人自动转发对我的新评论到我的xmpp客户端

测试通过

• 微博机器人自动转发关注我的新粉丝提醒到我的xmpp客户端

测试通过

• 微博机器人自动转发我关注的人的新微博到我的xmpp客户端

测试通过，当网页微博已经处于登录状态时似乎不会触发这个动作

• 微博机器人自动转发我的私信到我的xmpp客户端

测试通过

以下是具体操作步骤：

1. 使用浏览器登录到自己的新浪微博，如 http://weibo.com/xmppcn
2. 点击右上的"工具"菜单，进入到工具页面,这个页面的第一个标签应该是"聊天机器人"
3. 选择"GTALK"图标，在下面填入你的xmpp帐号,如 helpdesk@jabbercn.org
4. 点击"确定"按钮，会出现一个"验证码"
5. 打开xmpp客户端，登录到xmpp帐号，即上述的 helpdesk@jabbercn.org
6. 在xmpp客户端会收到一个添加好友请求，对方帐号类似 sinat019@gmail.com/F977FAA6 (注意每次绑定gtalk机器人时这个jid是不一样的，所以不要直接去加它为好友)
7. 同意新浪gtalk聊天机器人的好友请求并把它加为好友，然后拷贝前面从新浪微博网页上获得的"验证码"到聊天窗口，发送给新浪gtalk机器人
8. 如果一切正常，会收到新浪gtalk聊天机器人的回复，"[通知] 验证成功！输入/help可以查看帮助。"

RFC6120中的TLS重协商

RFC6120在STARTTLS协商这一章，增加了对可选的TLS重协商的描述，这个功能有三个用途:
1. 刷新密钥，对于长连的客户端/服务器来说，这很容易理解
2. 重新封装序列号，这个在TLS协议里有规定，序列号是一个自动增加的号码，是不可重新封装的，必须以重协商来代替
3. 双向的证书验证，这是最主要的用途，在普通的TLS连接中，只有服务器有证书，客户端验证了服务器的证书就可以协商成功了；在双向证书验证的情况下，还需要服务器对客户端的证书进行验证，最后才能协商成功，这就是重协商的用途了。
这个用法在 RFC3920没有提及，但是实际上多年前(至少5年前)国外已经有商业XMPP服务提供商是采用了双向证书验证。由于服务器要验证每个客户端的证书，登录过程是比较慢的，基本上超出了用户忍耐的极限。只有少数安全性要求很高而网络和软硬件条件很好的商用系统采用了这种做法。

简单说下MSN是如何支持XMPP的

MSN目前只是部分支持XMPP，主要是登录，和已有的好友聊天，查看好友名片，它的原理大致如下:
1. 第三方XMPP客户端先申请一个客户号，这代表第三方应用本身。
2. 客户端让用户使用Oauth2.0机制来登录MSN帐号(和新浪微博一样)，登录成功MSN服务器返回给客户端一个令牌
3. 客户端使用XMPP协议去连接messenger.live.com（SRV记录）或xmpp.messenger.live.com(A记录)的5222端口，连接必须使用SSL，验证机制采用X-MESSENGER-OAUTH2和SASL，使用步骤2得到的令牌去MSN的XMPP服务器验证身份，而不是使用传统的JID帐号和密码
常用的SASL验证过程如下

S: <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
      <mechanism>PLAIN</mechanism>
    </mechanisms>
    <c hash="sha-1" node="http://www.process-one.net/en/ejabberd/" ver="k87......lysI=" xmlns="http://jabber.org/protocol/caps">
    <register xmlns="http://jabber.org/features/iq-register" />
C: <auth mechanism="PLAIN" xmlns="urn:ietf:params:xml:ns:xmpp-sasl">aGVscGRl......uLA==</auth>
S: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" />

msn的XMPP服务的SASL验证过程如下

S: <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
     <mechanism>X-MESSENGER-OAUTH2</mechanism>
    </mechanisms> 
C: <auth mechanism="X-MESSENGER-OAUTH2" xmlns="urn:ietf:params:xml:ns:xmpp-sasl">EwAgAq1DBAAUlb......xHJQAAA%3d%3d</auth>
S: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" />

4. 从messenger.live.com验证成功后，MSN的XMPP服务器返回一个JID给客户端，这个JID不同于用户的MSN帐号，而是服务器分配的一个JID(用户使用同一MSN帐号登录，XMPP服务器仍会分配同一个JID给他),这个JID的格式为"xxxxxxxxxxx@messenger.live.com"
常见的资源绑定方式,jid是SASL时已经提供了的，客户端向服务器提出一个资源申请，服务器一般照准，返回完整的jid

C: <iq id="rm2876_77" type="set">
     <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
      <resource>Rooyee</resource>
     </bind>
    </iq>
S: <iq id="rm2876_77" type="result">
     <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
      <jid>helpdesk@jabbercn.org/Rooyee</jid>
     </bind>
    </iq>

msn的XMPP的资源分配过程，不管客户端申请了什么资源，服务器只管返回自己认定的全jid

C: <iq id="rm2876_41" type="set">
     <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
      <resource>Rooyee</resource>
     </bind>
    </iq>
S: <iq id="rm2876_41" type="result">
     <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
      <jid>26......5c@messenger.live.com/{ad......d}</jid>
     </bind>
    </iq>

撰写本文的这个时候. 微软的XMPP服务只支持部分的RFC6120和RFC6122（不支持好友列表管理），支持vCard(XEP-0054，不支持管理vCard)，支持聊天状态通知(XEP-0085)，支持延迟发送(http://xmpp.org/extensions/xep-0203.html)
另外，由于目前还是beta阶段，MSN的XMPP服务器很不稳定，经常登不上
参考：http://msdn.microsoft.com/en-us/windowslive/hh528487

linyu19872008开启了XEP-0016的翻译工作

linyu19872008 开启了 XEP-0016 一文的翻译工作

Yaohuan参与RFC6120翻译

Youhuan 参与 RFC6120 一文的翻译工作