gloox1.0使用Emai格式的账号登录

 今天研究gloox库，我使用的是最新发布版gloox1.0版本。听一个朋友说可以用Email格式账号登录，于是我想试试，直接用的Gloox库的示例代码，加上Email账号：如下

JID jid( "zhaoze87@163.com@pc-201006241430/gloox" ); j = new Client( jid, "123" ); j->registerConnectionListener( this ); j->registerMessageSessionHandler( this, 0 ); j->disco()->setVersion( "messageTest", GLOOX_VERSION, "Linux" ); j->disco()->setIdentity( "client", "bot" ); j->disco()->addFeature( XMLNS_CHAT_STATES ); StringList ca; ca.push_back( "/path/to/cacert.crt" ); j->setCACerts( ca ); j->logInstance().registerLogHandler( LogLevelDebug, LogAreaAll, this );

  这里有个问题要注意了，在Jabber里面。JID的格式是[账号]@[服务器地址]/[绑定资源名]，如果我们用Email账号zhaoze87@163.com@pc-201006241430/gloox，默认情况下在Gloox库的JID类里面，就会被这样解释了[zhaoze87]@[163.com@pc-201006241430]/[gloox],这样很明显就会出问题了，那这个怎么解决呢？？

  Gloox库实现的XMPP协议，作为一个标准协议，肯定考虑了上面这样的问题。在XMPP的扩展协议XEP-0106里面就有说明，如果在账号中包含了在协议里面定义的特殊字符，要进行转义，用转义符代替，这里只说明"@"应该用"/40"代替。所以上面的JID再被解析之前应该这样zhaoze87//40163.com@pc-201006241430/gloox,账号被解析成"zhaoze87//40163.com"

这里有两种方式，一些在 代码JID jid( "zhaoze87@163.com@pc-201006241430/gloox" );将用户名格式转换成zhaoze87//40163.com@pc-201006241430/gloox，这个是在Gloox调用模块改，Gloox::JID有个静态函数
 static std::string escapeNode( const std::string& node );可以实现这样的功能，将"@"转换成"//40“,还有一种方式是修改Gloox库，我就是用的第二种方式，在Gloox::JID::setJID中将 const std::string::size_type at = jid.finds( '@' );改成 const std::string::size_type at = jid.find_last_of( '@' );从最后一个'@'字符截断，前面都是用户名，然后将后面几行的代码稍微改动一下：

 if( at != std::string::npos && !( m_valid = prep::nodeprep( jid.substr( 0, at ), m_username ) ) ) return false; if (m_username.find('@') != m_username.npos) m_username = escapeNode(m_username);

  这样完成了带@JID的转化，于是我就尝试着登录看看，令我感到郁闷，居然没有登录成功，用本地OpenFire服务器，在Sasl验证的时候一直出错；但是我设置登录Gtak服务器，以Email账号的方式就可以成功。虽然郁闷但是Gtalk能登录成功至少说明我上面那样改应该是没有问题，那到底是哪里出了问题呢？？

  经过一番折腾，终于让我发现了一个问题，在Sasl验证过程中，Openfire服务器有返回了两种验证机制，一种是“DigestMd5”，还有一种是“Plain”，通过代码跟踪发现在Gloox中优先是采用“DigestMd5”,而登录Gtalk服务器的时候只有“Plain”验证机制，那我在Gloox中优先采用“Plain”验证机制好了。说做就做，找到验证选择的代码处

 bool Client::login() { bool retval = true; if( m_streamFeatures & SaslMechDigestMd5 && m_availableSaslMechs & SaslMechDigestMd5 && !m_forceNonSasl ) { notifyStreamEvent( StreamEventAuthentication ); startSASL( SaslMechDigestMd5 ); } else if( m_streamFeatures & SaslMechPlain && m_availableSaslMechs & SaslMechPlain && !m_forceNonSasl ) { notifyStreamEvent( StreamEventAuthentication ); startSASL( SaslMechPlain ); } else if( m_streamFeatures & StreamFeatureIqAuth || m_forceNonSasl ) { notifyStreamEvent( StreamEventAuthentication ); nonSaslLogin(); } else retval = false; return retval; }

将“Plain”验证机制提前，于是改成这样：

bool Client::login() { bool retval = true; if( m_streamFeatures & SaslMechPlain && m_availableSaslMechs & SaslMechPlain && !m_forceNonSasl ) { notifyStreamEvent( StreamEventAuthentication ); startSASL( SaslMechPlain ); } else if( m_streamFeatures & SaslMechDigestMd5 && m_availableSaslMechs & SaslMechDigestMd5 && !m_forceNonSasl ) { notifyStreamEvent( StreamEventAuthentication ); startSASL( SaslMechDigestMd5 ); } else if( m_streamFeatures & StreamFeatureIqAuth || m_forceNonSasl ) { notifyStreamEvent( StreamEventAuthentication ); nonSaslLogin(); } else retval = false; return retval; }

然后再登录OpenFire试试，终于成功了，OK，就是这样，虽然可以了，但是“DigestMd5”方式为什么会验证失败呢？这个我还是不知道什么原因，希望有哪位大牛比较熟悉能告诉我一下。