64位libjingle无法解析登录XML，出现expat错误:error_INVALID_TOKEN

64-bit libjingle failing to parse login XML with expat error: ERROR_INVALID_TOKEN

本文关键字：错误 expat error INVALID 出现 TOKEN libjingle XML 登录 64位      更新时间：2023-10-16

只有当我试图在64位下运行登录代码时，我才无法登录talk.google.com进行初始测试。32位运行良好。

启用日志宏和siginput日志后，我可以看到它失败的XML是：

<stream:stream from="gmail.com" id="3D9A4487B8514DE2" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">232231377

在外籍人士内部，我可以看到有一个XML_ERROR_INVALID_TOKEN正在被抛出，但我不太确定从那里去哪里。有时，它可以进行实际登录，但很快就会失效。它看起来是相对随机的，但总是在前10个响应内死亡。我知道最后的垃圾数据可能是导致无效令牌的原因，但不确定是什么原因导致的。

我最初的想法是在切换到64位（？？）时出现编码问题，但老实说，我只是不知道是什么导致了这样的事情发生。

以下是libjingle死亡日志中的另一个示例片段：

137[000:568] RECV <<<<<<<<<<<<<<<<<<<<<<<<< : Thu Feb 21 00:01:31 2013
[000:568]    332
[000:568]    <iq id="2" type="result">
[000:568]      <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
[000:568]        <jid>
[000:568]          snip@gmail.com/CD6FF
[000:568]        </jid>
[000:568]      </bind>
[000:568]    </iq>
<iq id="2" type="result"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>snip@gmail.com/CD6FF</jid></bind></iq>x332Mhanism>X-OAUTH2</mechanism></mechanisms></stream:features>p

另一个：

[000:217]    <stream:stream from="gmail.com" id="2462F624C942" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">
<stream:stream from="gmail.com" id="246E4B24C942" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">225231377

另一个：

139[000:178] RECV <<<<<<<<<<<<<<<<<<<<<<<<< : Thu Feb 21 00:20:52 2013
[000:178]    <stream:stream from="gmail.com" id="B15C99514B664586" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">
<stream:stream from="gmail.com" id="B15C99514B664586" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">366231377

另一个：

52[000:243] RECV <<<<<<<<<<<<<<<<<<<<<<<<< : Thu Feb 21 00:23:44 2013
[000:243]    Q
[000:243]    <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>
<success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>261xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>X-GOOGLE-TOKEN</mechanism><mechanism>X-OAUTH2</mechanism></mechanisms></stream:features>Q

以前有人遇到过这种问题吗？

假设ddd序列表示八进制数，则流中包含无效utf-8中的代码点，这可能是xml数据流的默认预期编码。

在将内容提供给xml解析器之前，您必须用数字实体替换有问题的字节，例如231->&#x99;。

另一种选择可能是在xml数据流前面加一个xml prolog，声明一些8位字符集，例如<?xml version="1.0" encoding="iso-8859-1" ?>。

希望它能有所帮助，关于

看起来这是我使用的openssl 64位构建的问题。不知道构建出了什么问题，但我所要做的就是切换到libssl0.9.8和libcrypto0.9.8 dylib版本，一切都很好。

希望这将帮助其他人诊断SSL交互中的奇怪垃圾。

相关文章：