青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

面對現(xiàn)實,超越自己
逆水行舟,不進則退
posts - 269,comments - 32,trackbacks - 0

引文:

調(diào)試GLOOX 1.0.10的注冊功能頗費了一些功夫。總體邏輯如GLOOX自帶的例子一樣是毫無疑問的,但是照搬例子又是不能完成注冊的,返回錯誤碼為4------RegistrationBadRequest筆者一開始在網(wǎng)上狂搜解決方案,資料少之又少,有建議重寫Client::handleNormalNode函數(shù)(目的是禁止SASL認證)的,有直接繼承Client重寫Client::handleNormalNode函數(shù)的,但都沒說到點子上。經(jīng)過一段時間的研究,在GLOOX的maillist上得到啟發(fā),順利完成注冊。現(xiàn)將解決方案記錄下來:


環(huán)境

客戶端:GLOOX1.0.1.0 VS2008

服務器:OPENFIRE 默認安裝


對于GLOOX自帶的注冊例子不能正常注冊的問題有人在郵件列表里提出來。一個哥們這樣回答:

Ok, I've found what the problem was 
In openFire server parameters, Anonymous Login => Disabled !!! 

意思是要禁用openFire服務器里的選項”注冊和登錄“的”匿名登錄“項

筆者按此說明禁用該選項,果然注冊成功。

這說明開始的注冊失敗是和匿名登錄有關系的。我們來看一下引用registration_expmple例子登錄失敗時的XML流:

S->C:服務器返回給客戶端支持的認證機制:

<stream:features xmlns:stream='http://etherx.jabber.org/streams'><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism><mechanism>CRAM-MD5</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> 

 

從上面XML流中我們可以看到,默認openFire支持四種認證機制,分別是:DIGEST-MD5、PLAIN、ANONYMOUS、CRAM-MD5。然后我們看GLOOX客戶端的響應流:

C->S:客戶端返回選擇的認證方式:

<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='ANONYMOUS'/>

可以看出,客戶端”無恥“的選擇了”匿名“--
'ANONYMOUS'方式

接下來的流程就是客戶端”無恥“的選擇了以匿名的方式登錄了服務器,然后再發(fā)送注冊請求,請求如下:

<iq id='uid:4e69eccd:00006784' type='set' from='447e0585@zxl/447e0585' xmlns='jabber:client'><query xmlns='jabber:iq:register'><username>bbaxiao</username><password>123456</password><name>test2</name><email>163@gmail.com</email></query></iq> 

我們看到,IQ節(jié)里包含“form”屬性,即客戶端匿名身份標識。

注意,一個客戶端已經(jīng)以一個身份(由服務器臨時分配的一個JID)登錄,建立了會話,在服務器上我們會看到這個會話,并且服務器發(fā)送心跳一直維護這個會話。這種情況下,這個客戶端再發(fā)送注冊請求(另一個身份)建立與服務器的連接是不被允許的。具體請參考XEP-0077(In-Band Registration):我們關注這兩段:

If the entity cancels its registration with its "home" server (i.e., the server at which it has maintained its XMPP account), then the entity SHOULD NOT include a 'from' or 'to' address in the remove request the server SHOULD then return a <not-authorized/> stream error and terminate all active sessions for the entity. The server SHOULD perform the remove based on the bare JID <localpart@domain.tld> associated with the current session or connection over which it received the remove request. If the server is an instant messaging and presence server that conforms to XMPP IM [8], the server SHOULD also cancel all existing presence subscriptions related to that entity (as stored in the entity's roster). 
 
If the entity cancels its registration with a service other than its home server, its home server MUST stamp a 'from' address on the remove request, which in accordance with XMPP Core will be the entity's full JID <localpart@domain.tld/resource>. The service MUST perform the remove based on the bare JID <localpart@domain.tld> portion of the 'from' address. 

If the entity cancels its registration with its "home" server (i.e., the server at which it has maintained its XMPP account), then the entity SHOULD NOT include a 'from' or 'to' address in the remove request the server SHOULD then return a <not-authorized/> stream error and terminate all active sessions for the entity. The server SHOULD perform the remove based on the bare JID <localpart@domain.tld> associated with the current session or connection over which it received the remove request. If the server is an instant messaging and presence server that conforms to XMPP IM [8], the server SHOULD also cancel all existing presence subscriptions related to that entity (as stored in the entity's roster).  
  
If the entity cancels its registration with a service other than its home server, its home server MUST stamp a 'from' address on the remove request, which in accordance with XMPP Core will be the entity's full JID <localpart@domain.tld/resource>. The service MUST perform the remove based on the bare JID <localpart@domain.tld> portion of the 'from' address.  

 

意思是說注冊請求不能包含“from”屬性。

正常的注冊流如下:

<iq id='uid:4e69eccd:00003d6c' type='set' xmlns='jabber:client'><query xmlns='jabber:iq:register'><username>bbaxiao</username><password>123456</password><name>test2</name><email>163@gmail.com</email></query></iq> 

---------------------------

綜上所述,解決方案如下:

一、關閉openFire的匿名登錄功能。^_^……

二、禁止GLOOX匿名認證功能。

file:client.cpp 
 
fun: int Client::getSaslMechs( Tag* tag ) 
 
line:423 
 
//將423行注釋掉即可。 
422:if( tag->hasChildWithCData( mech, "ANONYMOUS" ) ) 
423      //mechs |= SaslMechAnonymous; 

重新編譯生成DLL即可。

三、手動設置GLOOX客戶端SASL認證機制

在調(diào)用j->connect()之前設置SASL認證機制,比如設置為“DIGEST-MD5”


j->setSASLMechanisms(SaslMechDigestMd5);

這種方式的缺點是需要先確定服務器支持的認證機制。

四、根據(jù)XEP-0077所述,即使其名登錄,注冊流只要不帶“from”屬性應該也可以。所以我們要處理發(fā)出的注冊流,去除“from”屬性重新發(fā)送注冊流即可。


本文轉(zhuǎn)自:http://blog.csdn.net/abcpanpeng/article/details/7370974


posted on 2014-08-28 17:59 王海光 閱讀(1563) 評論(0)  編輯 收藏 引用 所屬分類: Openfire&Gloox

只有注冊用戶登錄后才能發(fā)表評論。
網(wǎng)站導航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            国产欧美日韩精品一区| 在线观看三级视频欧美| 一区二区三区黄色| 亚洲精品一区二区网址| 欧美黑人在线播放| 亚洲午夜一二三区视频| 亚洲免费伊人电影在线观看av| 国产精品日韩电影| 久久久久久午夜| 久久综合九色综合欧美狠狠| 最近中文字幕日韩精品| 99精品欧美一区二区蜜桃免费| 欧美日韩中文字幕在线| 欧美在线高清| 久久精品一区二区| 一本色道久久综合亚洲精品高清| 一区二区三区免费观看| 国产一区二区三区免费不卡 | 欧美福利一区二区| 中文日韩在线| 一区精品久久| 日韩午夜中文字幕| 国产一区二区高清视频| 亚洲精品久久久一区二区三区| 欧美特黄一区| 麻豆freexxxx性91精品| 欧美体内she精视频| 久久综合久久综合久久| 欧美日韩人人澡狠狠躁视频| 久久精品一区四区| 欧美女同视频| 麻豆九一精品爱看视频在线观看免费| 欧美日本精品| 免费人成精品欧美精品| 国产精品久久久久av| 亚洲电影免费| 国产亚洲精品aa| 亚洲毛片网站| 亚洲高清精品中出| 午夜视频一区| 亚洲欧美成人一区二区三区| 欧美va天堂va视频va在线| 午夜在线电影亚洲一区| 欧美久久电影| 欧美激情影院| 在线播放豆国产99亚洲| 欧美一区二区高清| 亚洲欧美日韩精品久久亚洲区| 欧美国产精品一区| 男人的天堂亚洲| 国产在线国偷精品产拍免费yy| 日韩亚洲欧美一区二区三区| 亚洲欧洲三级| 蜜臀av一级做a爰片久久| 久久久久国产一区二区三区四区 | 亚洲一区成人| 亚洲视频网站在线观看| 欧美日本精品一区二区三区| 欧美激情一区二区三区四区| **网站欧美大片在线观看| 久久精品99国产精品| 欧美在线一区二区| 国产欧美日韩在线视频| 亚洲专区一二三| 欧美一级网站| 国产亚洲免费的视频看| 欧美一区二区三区四区夜夜大片 | 久久精品国产亚洲精品| 国产欧美精品在线观看| 西西裸体人体做爰大胆久久久| 午夜亚洲伦理| 国产亚洲欧美日韩日本| 久久精品72免费观看| 麻豆国产精品va在线观看不卡| 激情欧美日韩一区| 久久最新视频| 亚洲免费电影在线| 午夜精品久久久久久久久久久久 | 亚洲国产精品久久久久| 免费不卡视频| 亚洲免费精品| 亚洲欧美美女| 精品88久久久久88久久久| 老牛国产精品一区的观看方式| 欧美国产欧美亚州国产日韩mv天天看完整| 亚洲高清123| 欧美视频一区二区三区在线观看| 亚洲校园激情| 久久综合图片| 一区二区日韩精品| 国产欧美一区二区精品秋霞影院 | 亚洲精品乱码久久久久久蜜桃91| 一区二区三区精品视频在线观看| 国产精品www网站| 久久国产精品久久久| 亚洲激情网站免费观看| 亚洲欧美日韩一区在线| 激情久久久久久久| 欧美日韩黄色大片| 久久经典综合| 99国产一区| 噜噜噜噜噜久久久久久91| 亚洲少妇诱惑| 在线观看亚洲视频| 国产精品第一区| 噜噜噜91成人网| 亚洲自拍三区| 亚洲欧洲精品天堂一级| 久久精品亚洲一区| 夜夜爽99久久国产综合精品女不卡 | 另类激情亚洲| 国产精品99久久久久久久女警| 国产综合色精品一区二区三区| 欧美巨乳在线| 久久精品免费电影| 亚洲香蕉成视频在线观看| 亚洲第一二三四五区| 久久激情久久| 亚洲制服少妇| 一本色道久久综合亚洲精品不卡| 影音先锋久久久| 国产精品亚洲аv天堂网| 欧美精品在线一区| 欧美ed2k| 久久尤物视频| 久久久亚洲高清| 欧美一区二区三区视频| 亚洲一级电影| 中文亚洲欧美| 亚洲精品一线二线三线无人区| 欧美大尺度在线| 美女尤物久久精品| 久久五月婷婷丁香社区| 欧美一区二区性| 欧美亚洲一区| 亚洲欧美激情精品一区二区| 一区二区三区四区五区视频| 日韩一级成人av| 999亚洲国产精| 亚洲精品在线观看视频| 亚洲精品你懂的| 亚洲日韩欧美一区二区在线| 亚洲高清免费| 亚洲欧洲日本专区| 亚洲狼人精品一区二区三区| 亚洲精品色图| 亚洲毛片在线| 一区二区三区日韩欧美| 亚洲色诱最新| 亚洲欧美日韩精品久久久久| 欧美一区二区女人| 久久女同精品一区二区| 久久夜色精品国产| 欧美成人高清视频| 亚洲国产精品黑人久久久| 亚洲黄网站黄| 在线亚洲国产精品网站| 这里只有精品丝袜| 亚洲在线免费观看| 久久精品在线播放| 欧美顶级艳妇交换群宴| 欧美吻胸吃奶大尺度电影| 国产精品亚洲一区| 狠狠色综合色区| 亚洲乱码国产乱码精品精98午夜| 9久草视频在线视频精品| 亚洲欧美日韩成人| 久久久综合网站| 亚洲国产美女| 亚洲专区国产精品| 久久综合亚洲社区| 欧美色精品天天在线观看视频 | 久久精品男女| 欧美久久一区| 国产日产精品一区二区三区四区的观看方式 | 国产一区导航| 99re这里只有精品6| 亚洲欧美日韩综合国产aⅴ| 久久人人97超碰国产公开结果 | 亚洲高清久久| 亚洲主播在线播放| 另类综合日韩欧美亚洲| 国产精品美女| 亚洲人妖在线| 久久国产精品一区二区| 女仆av观看一区| 亚洲欧美成人网| 欧美—级a级欧美特级ar全黄| 国产精品三区www17con| 亚洲人成网站在线观看播放| 欧美在线播放视频| 91久久精品国产91性色tv| 欧美一级片一区| 欧美三区免费完整视频在线观看| 一区二区三区在线视频播放| 亚洲欧美视频| 亚洲人成网站色ww在线| 久久免费视频一区| 国产日韩一区| 亚洲欧美日韩精品久久奇米色影视|