In my chat project I’m using XIFF API and I want to connect to Jabber.org server. XIFF suports SASL PLAIN, ANONYMOUS and EXTERNAL and since I want to do non-anonymous login so I can use only SASL PLAIN and EXTERNAL. but Jabber.org does not support latter so only 1 option remains - SASL PLAIN.
My client is unable to login using SASL PLAIN and I get 401: Authentication Error from server. I have confirmed dozens of times and my username and password input is correct (I cross checked by logging in a different client using my jabber.org credentials.)
Can someone put any light on this issue?? Its making me go mad!!!
_conn = new XMPPBOSHConnection();
setupConnectionListeners(); //setup all listeners like ConnectionSuccessEvent.CONNECT_SUCCESS etc.
_conn.server = DEFAULT_SERVER_LOCATION; //sets correct location like “mydomain.com”
_conn.username = un; //input from UI
_conn.password = pwd; //input from UI
_conn.resource = “myClient”;
The url of HTTPRequest object (function sendRequest() in XMPPBOSHConnection) points to correct, working location of HTTP-Binding utility of the Openfire server installed on my system.
The method used in SASL PLAIN and the file used is Plain.as (lying in \org\jivesoftware\xiff\auth) and is attached herewith.
Tell me if you need more code. Plain.as.zip (1380 Bytes)
My AUth problem got solved when I changed the format of username and password in packet to username@jabber.org/0username/0password and I started getting authentication success from Jabber.org server. But After XMPP Restart when the client sends resource binding packet I do not receive any response from Jabber.org apart from packet and after some time session times out.
Following are the logs from the client…
First request to server…
sending request…
Error: Ignoring policy file requested from http://jabber.org/crossdomain.xml because a cross-domain redirect to http://www.jabber.org/crossdomain.xml occurred.
Received from server…
zlibDIGEST-MD5PLAIN
sending request…
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx< /auth>
Received from server…
sending request…
Received from server…
sending request…
tab_client
Received from server…
When I sniffed the network packets this was the last response before session timing out.
Delving more in the logs and BOSH implementation details I can see that I’m not getting any response from Jabber.org server for XMPP restart packet.
After this i Send resource binding packet but since the stream hasn’t restarted I dont get that either.
Now what is the reason behind eJabberD 2.x version (Jabber.org) not responding to it? During my search and logs from successfully connecting client I see that XIFF is not sending the OPEN stream tag prior to XMPP restart which is
I think this ia a bug and it should be logged in XIFF bug databse.
While using XIFF I’m unable to connect to Jabber.org server successfully. Though the Auth successfully happens (After I tweaked Plain.as a little bit.) but server never repiles to XMPP restart packet.
Any clues/ideas? I’m stcuk with client deployment on this very issues!!!
Meaning can you send a restart stream by hand and get it to work, with or without the closing slash?
I am happy to apply to the trunk if you can provide the fix and possibly explain the reason and possible part of a standard explaining the correct way.
I’m still using the last beta release (instead of trunk), but to get ejabberd to work you have to remove version=“1.0” from the end of the stream type.
In the beta release, it was line 108 of XMPPSocketConnection.
Once you remove that property, ejabberd will respond. From what I’ve read, this is an issue with XIFF and not ejabberd (but I’m not positive about that).
I would assume this would cause the same issue in XMPPBoshConnection.
Looking at the trunk, it looks like the version property still gets added, but on line 509 of XMPPConnection.
We need to officially find out if this is an issue with XIFF or ejabberd.
From what I’m looking at, when you pass version 1.0 it seems like ejabberd is saying “sweet, you guys are using version 1.0, here’s some extra stuff you guys can use”, and XIFF probably barfs on this (possibly because its not 100% version 1.0 compliant.
Because without the Version 1.0, its a very minimal response from ejabberd that XIFF seems to be able to handle nicely.
Mark did you use XMPPBoshConnection to connect to Jabber.org? Which http-binding have you used? Because yet I’m unable to do that.
Juga I dont have a working solution of the problem. I’m unable to solve it. I’m not getting response of XMPP Restart packet. I had taken Code of XIFF from trunk around 14th April’09 and have been using that with changes made to Plain.as for supporting Jabber.org’s authentication (After those changes only I was able to successfully connect to Jabber.org). I have already attached that file in this post earlier.
I have tried removing version=“1.0” from the packets in the past (I use XMPPBoshConnection) but That hasn’t worked. The client still fails to connect to Jabber.org.
Earlier I have mentioned in this post that perhaps by sending the OPEN <stream:stream to=“jabber.org” xmlns=“jabber:client” xmlns:stream=“http://etherx.jabber.org/streams” version=“1.0”> packet before XMPP restart I may be able to connect (On similar lines with XMPPSocketConnection). But while reading through XEP-0206 I noted that they have explicitly written that in BOSH connection that you dont need to send OPEN packets because simply they are ill-formed XML and that would not be allowed in BOSH. So that too is not needed.
I took code from trunk today and tried connecting to Jabber.org using XMPPBoshConnection. But stuck again on XMPP restart. No server response after that. while sniffing network packets I see that last packet received on Http-Binding is
<?xml version='1.0'?>
Dunno why I’m getting stream error on netwrok restart.
He did not apply the ejabberd patch that is floating around out there.
The biggest issue was that he had to serve up the crossdomain from the TCP port 843*.
He also had to make sure that the crossdomain was served no matter what, even on 404. When it didn’t return on 404, the connection still didn’t work. Once he did serve it up on 404, the connection was successful.
That’s all he had to do, besides me having to remove the “version” from XIFF, but that doesn’t seem necessary anymore.
We are not using BOSH, just the standard connection, so I’m not sure if that would cause any further issues.
*Adobe is applying with IANA, the Internet Assigned Numbers Authority, to reserve TCP port 843 for the purpose of serving socket policy files.
I would really appreciate if you could help me with BOSH connection issue coz I cant use socket connection in my app. I’ll discuss your suggestions on monday when i join back but any help on my issues wil BOSH connection will be a great help
because a cross-domain redirect to http://www.jabber.org/crossdomain.xml