Xmpp學習之Smack發送消息JID變亂碼

Xmpp學習之Smack發送消息JID變亂碼

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。

轉載請代表出處：http://www.cnblogs.com/cavalier-/p/6947723.html

快速導航,簡單來個目錄圖片。

前言

繼上一篇博客Android平臺使用Smack後，此次我們來分享一下在集成過程當中SASL認證的一些坑=_=。

在此爲後面的smack學習作筆記，以做備忘。
如下是本次採用的Demo環境:

• Openfire 3.8.2
• smack 4.2.1

登陸成功後發現jid變成 亂碼@亂碼

通常發生這種問題，在登陸時是沒問題的，可是當你想發送消息時，你會發現接收消息方的名字竟然是亂碼，下面我來講一下爲何會登陸成功，可是發送消息亂碼。

解決方案

解決方案很簡單，僅需在調用connection.Login()函數前先調用SASLAuthentication.blacklistSASLMechanism("ANONYMOUS");，把ANONYMOUS加入黑名單便可，下面我來講一下爲何會發生這種狀況。

如何證明

如何證明呢？我們來看一下鏈接socket後的第二條報文：

<?xml version='1.0' encoding='UTF-8'?>
    <stream:stream xmlns:stream="http://etherx.jabber.org/streams" 
    xmlns="jabber:client" from="im" 
    id="e26ece26" 
    xml:lang="en" 
    version="1.0">
    <stream:features>
        <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls">
        </starttls>
        <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
            <mechanism>PLAIN</mechanism>
            <mechanism>ANONYMOUS</mechanism>
            <mechanism>JIVE-SHAREDSECRET</mechanism>
        </mechanisms>
        <compression xmlns="http://jabber.org/features/compress">
            <method>zlib</method>
        </compression>
        <auth xmlns="http://jabber.org/features/iq-auth"/>
        <register xmlns="http://jabber.org/features/iq-register"/>
    </stream:features>

從上面的報文能夠看到服務器支持的 SASL 認證機制只有三種(大家的服務器不必定和我返回的認證機制同樣，這裏只是打個比方)，可是當你想設置PLAIN認證方式時，你會在API中發現竟然沒有設置惟一認證方式，且沒法設置優先級，由於ANONYMOUS的排序比PLAIN的順序前，因此SDK直接返回了ANONYMOUS，下面來看一下SASLAuthentication的Sasl認證是怎麼作的:

Iterator<SASLMechanism> it = REGISTERED_MECHANISMS.iterator();
final List<String> serverMechanisms = getServerMechanisms();
       、、、
// Iterate in SASL Priority order over registered mechanisms
while (it.hasNext()) {
    SASLMechanism mechanism = it.next();
    String mechanismName = mechanism.getName();
            、、、
            、、、
    if (serverMechanisms.contains(mechanismName)) {
        /* Create a new instance of the SASLMechanism 
        for every authentication attempt.
        return*/
         mechanism.instanceForAuthentication(connection, 
        configuration);
    }

經過以上源碼我們發現，無非就是String.contains()函數進行匹配字符串，那麼問題來了，若是ANONYMOUS的排序比PLAIN的順序前，則直接返回ANONYMOUS，怎麼看到系統的SASLMechanism排序呢？我們再來看下面的log:

W/System.err: org.jivesoftware.smack.SmackException: 
No supported and enabled SASL Mechanism provided by server. 
Server announced mechanisms: 
[PLAIN, ANONYMOUS, JIVE-SHAREDSECRET].
 Registerd SASL mechanisms with Smack: [
    SASL Mech: 
        SCRAM-SHA-1-PLUS, Prio: 100, 
        SASL Mech: SCRAM-SHA-1, Prio: 110, 
        SASL Mech: DIGEST-MD5, Prio: 210, 
        SASL Mech: PLAIN, Prio: 410, 
        SASL Mech: X-OAUTH2, Prio: 410, 
        SASL Mech: ANONYMOUS, Prio: 500, 
        SASL Mech: EXTERNAL, Prio: 510
]. Enabled SASL mechansisms for this connection: [PLAIN]. 
Blacklisted SASL mechanisms: [PLAIN, SCRAM-SHA-1-PLUS].

相信你們看到上面的log已經發現問題所在了，Prio是優先級，ANONYMOUS的優先級明顯高於PLAIN、DIGEST-MD5、X-OAUTH2等。

小知識

ANONYMOUS級別官方解釋是，匿名登陸，因此產生的JID是隨機生成的。

結尾

本篇博客簡單描述瞭如何解決SASL認證的一個小坑，歡迎支持。

引用

最新的smack接入指南連接:https://download.igniterealtime.org/smack/docs/latest/documentation/gettingstarted.html/

最新版smack JavaDoc連接:https://download.igniterealtime.org/smack/docs/latest/javadoc/