I am libstrophe example client program bot.c and trying to connect with ejabberd server.
I am facing authentication failure. Please refer the log below.
xmpp DEBUG Connecting via altdomain.
xmpp DEBUG sock_connect() to 127.0.0.1:5222 returned 3
xmpp DEBUG Attempting to connect to 127.0.0.1
xmpp DEBUG connection successful
conn DEBUG SENT: <?xml version="1.0"?><stream:stream to="prakash.com" xml:lang="en" version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams">
xmpp DEBUG RECV: <stream:stream id="16900185530209358531" version="1.0" lang="en" from="prakash.com">
xmpp DEBUG RECV: <features xmlns="http://etherx.jabber.org/streams"><c hash="sha-1" xmlns="http://jabber.org/protocol/caps" node="http://www.process-one.net/en/ejabberd/" ver="LSc28EBBWo2uA2P3nRDU+sBlbsc="/><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>DIGEST-MD5</mechanism><mechanism>X-OAUTH2</mechanism><mechanism>SCRAM-SHA-1</mechanism></mechanisms></features>
conn DEBUG SENT: <auth mechanism="SCRAM-SHA-1" xmlns="urn:ietf:params:xml:ns:xmpp-sasl">biwsbj1CVlAscj0zZjMwOTQ5N2IyYTEwZDYzNjUwZTRiNzEwMmY3Zjk1</auth>
xmpp DEBUG RECV: <failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><not-authorized/></failure>
xmpp DEBUG handle SCRAM-SHA-1 (challenge) called for failure
xmpp DEBUG SASL SCRAM-SHA-1 auth failed
conn DEBUG SENT: <auth mechanism="DIGEST-MD5" xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>
xmpp DEBUG RECV: <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">bm9uY2U9IjcwOTEwMTI1NzE1NzkzNzMyOTkiLHFvcD0iYXV0aCIsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M=</challenge>
xmpp DEBUG handle digest-md5 (challenge) called for challenge
conn DEBUG SENT: <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">dXNlcm5hbWU9IkJWUCIscmVhbG09InByYWthc2guY29tIixub25jZT0iNzA5MTAxMjU3MTU3OTM3MzI5OSIsY25vbmNlPSJhMjZkZWQ0M2Y4MmMiLG5jPTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvcHJha2FzaC5jb20iLHJlc3BvbnNlPWEyYTVlMDIwYTNkZjc1NmY1NTAxZDBkYzMyMDliOGQ5LGNoYXJzZXQ9dXRmLTg=</response>
xmpp DEBUG RECV: <failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><not-authorized/></failure>
xmpp DEBUG handle digest-md5 (rspauth) called for failure
xmpp DEBUG SASL DIGEST-MD5 auth failed
conn DEBUG SENT: <auth mechanism="PLAIN" xmlns="urn:ietf:params:xml:ns:xmpp-sasl">AEJWUABhZG1pbjEyMw==</auth>
xmpp DEBUG RECV: <failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><not-authorized/></failure>
xmpp DEBUG SASL PLAIN auth failed
auth ERROR Cannot authenticate without resource
conn DEBUG SENT: </stream:stream>
xmpp DEBUG RECV: </stream:stream>
xmpp DEBUG Closing socket.
DEBUG: disconnected
event DEBUG Stopping event loop.
event DEBUG Event loop completed.
Can someone help me on this how to resolve this authentication problem?
Libstrophe tries supported authentication mechanisms one by one until one succeeds or all fail. The problem is on server side and given logs don't provide enough information to reveal it.
SCRAM-SHA-1 mechanism fails after the 1st stanza. This means that server rejects authentication when only username is sent. I would suggest to check if such a user exists (I'm not sure if it case-sensitive). If this doesn't help look at ejabberd logs.
Take into account that PLAIN mechanism sends base64-encoded login/password and anyone can decode it. Therefore, I would suggest to remove encoded password from libstrophe's logs like this:
conn DEBUG SENT: <auth mechanism="PLAIN" xmlns="urn:ietf:params:xml:ns:xmpp-sasl">*REDACTED*</auth>
When all authentication mechanisms fail libstrophe tries legacy client authentication. In this case it needs a resource to build <iq> stanza. Logs show the next error message since a resource was not added to jid:
auth ERROR Cannot authenticate without resource
When login/password are correct and there is no problem with jabber server the authentication should succeed on the 1st supported mechanism and legacy authentication shouldn't be called. Therefore, it is safe to ignore the last error message.
Edit the below parameters in ejabbered.yml file.
auth_password_format: scram
s2s_protocol_options:
- "no_sslv3"
save the file .
Stop and start the ejabbered Server.
Now Register the user in the server side and run the bot example in the libstrophe library.
I am trying to figure out what FIX resend (35=2) do , so I have my own FIX engine
to send the following message to FIX acceptor :
Notice : The following messages has 0x01 replaced by '|' already !!
Step1 :
logon : (8=FIX.4.2|9=86|35=A|34=12|49=YADTS|52=20160316-11:22:43.000|56=DS68AA|96=13575522|98=0|108=30|10=162|)
Step2:
receive : (8=FIX.4.2|9=00073|35=A|49=DS68AA|56=YADTS|34=9|52=20160316-03:22:48.744|108=30|98=0|10=200|)
logon looke like works !!!
Step3:
client resend request to accptor :
(8=FIX.4.2|9=72|35=2|34=13|49=YADTS|52=20160316-11:22:48.000|56=DS68AA|7=2|16=0|10=166|)
Step4:
client send heartbeat to accetor :
(8=FIX.4.2|9=62|35=0|34=14|49=YADTS|52=20160316-11:23:12.000|56=DS68AA|10=032|)
Step5:
accptor send to client :
(8=FIX.4.2|9=00072|35=2|49=DS68AA|56=YADTS|34=10|52=20160316-03:23:17.677|7=13|16=0|10=119|)
Step6:
acceptor send to client :
(8=FIX.4.2|9=00128|35=5|49=DS68AA|56=YADTS|34=11|52=20160316-03:23:47.676|58=A timeout occurred while waiting for a resend request response|10=232|)
What I am bothered is , in Step5 , I am asking resend request with begin_seqno=2(7=2) to the last seqno (16=0) in Step3 .
But , Why in Step5 ,the accptor send resend request to client ?
Should not acceptor should resend message which seqno between 2 to the last ?!
I have no idea Why acceptor send the 35=2 message to client for ,
any commets are great appreciated !!
I am working on a chat application and using Fastpath plugin of Openfire Chat server for workgroups and queues.
When a user is sending a chat invitation/offer to workgroup it is going to all the agents available in the workgroup, on round robin fashion. when the one of agents accepts chat invitation/offer I am sending following info query to server which works fine because once the agent accept chat invitation/offer same offer don't goes to other users.
this is the info query string :-
<iq to="test-home#workgroup.domain" id="833-197" type="set" xmlns="jabber:client">
<offer-accept jid="sender#workgroup.domain" id="offerId" xmlns="http://jabber.org/protocol/workgroup">
</offer-accept>
</iq>
but when agent rejects the offer I am sending following info query, which is not working, and the same user is getting invitation/offer again and again
<iq to="test-home#workgroup.domain" id="833-197" type="set" xmlns="jabber:client">
<offer-reject jid="sender#workgroup.domain" id="offerId" xmlns="http://jabber.org/protocol/workgroup">
</offer-reject>
</iq>
I have a running ejabberd installation, with http-bind enabled, nginx proxy, and a mini jappix xmpp client for web browsers. I also have an external authentication program.
I can connect the same user on this server with different ressources if I use the classical 5222 port. But:
If I have active sessions from classical xmpp clients (psi, empathy) for a given user I cannot connect this user with http-bind (401 authentication failure).
I the first connection is made via http-bind no other connection can be done by other classical xmpp clients (and resources are of course different). I sometimes get the 401 already connected message
I can only connect the same user in one browser, I cannot connect the same user several time on http-bind (resources are different on theses connections, but I also get a 401)
I'm sure the external authentification program is never launched when I get theses auth failure
max_user_sessions settings are ok (tested with infinity), and if I'm not connecting in http-bind I can run parallel sessions. But in case of I also tested the new resource_conflict setting values without any success (and it's not a re'source conflict in fact)
Installation: ejabberd-2.1.10 Debian (from ejabberd-2.1.10-linux-x86-installer.bin, but same problem tested in x86_64 version).
Extract of configuration:
{5280, ejabberd_http, [
{request_handlers,
[
{["http_bind"], mod_http_bind}
]},
%%captcha,
http_bind,
%%http_poll,
web_admin
]}
On the logs, when this is happening I have:
=INFO REPORT==== 2012-01-27 10:18:55 ===
D(<0.335.0>:ejabberd_http_bind:684) : reqlist: [{hbr,154037,
"01775ec6fc089a2b0c84abb80a4b5b7b4bdd958d",
[]},
{hbr,154036,
"01775ec6fc089a2b0c84abb80a4b5b7b4bdd958d",
[{xmlstreamelement,
{xmlelement,
"stream:features",[],
[{xmlelement,
"mechanisms",
[{"xmlns",
"urn:ietf:params:xml:ns:xmpp-sasl"}],
[{xmlelement,
"mechanism",[],
[{xmlcdata,
"PLAIN"}]}]}]}},
{xmlstreamstart,
"stream:stream",
[{"version","1.0"},
{"xml:lang","fr"},
{"xmlns","jabber:client"},
{"xmlns:stream",
"http://etherx.jabber.org/streams"},
{"id","3595609800"},
{"from",
"tchat.example.com"}]}]}]
=INFO REPORT==== 2012-01-27 10:18:55 ===
D(<0.335.0>:ejabberd_http_bind:732) : really sending now: [{xmlelement,
"auth",
[{"xmlns",
"urn:ietf:params:xml:ns:xmpp-sasl"},
{"mechanism",
"PLAIN"}],
[{xmlcdata<<"bGRhcHVzZX(...)3">>}]}]
=INFO REPORT==== 2012-01-27 10:18:55 ===
I(<0.336.0>:ejabberd_c2s:649) : ({socket_state,ejabberd_http_bind,{http_bind,<0.335.0>,{{127,0,0,1},50992}},ejabberd_http_bind}) Failed authentication for foo38#tchat.example.com
=INFO REPORT==== 2012-01-27 10:18:55 ===
D(<0.337.0>:ejabberd_http_bind:916) : OutPacket: [{xmlstreamelement,
{xmlelement,"failure",
[{"xmlns",
"urn:ietf:params:xml:ns:xmpp-sasl"}],
[{xmlelement,
"not-authorized",[],
[]}]}}]
=INFO REPORT==== 2012-01-27 10:18:55 ===
D(<0.337.0>:ejabberd_http_bind:1054) : --- outgoing data ---
<body xmlns='http://jabber.org/protocol/httpbind'><failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><not-authorized/></failure></body>
So is this a "feature" in http-bind ? making it the only valid Resource for a given user while activated? And how to run several http-binded sessions for the same user if so? Any hints?
No there must be something wrong with your configuration. I have been successfully using ejabberd's http-bind for a long time and of course you can have multiple connections with different resources and independently of other clients connecting. I also use nginx as a proxy. In you ejabberd.cfg you should have:
{5280, ejabberd_http, [
http_bind,
web_admin
]}
and
{modules,[
{mod_http_bind,[]},
...
]}.
Also, in your logs I see {"from", "tchat.example.com"}, which seems to indicate a missconfiguration.
I have set up the following publisher in CruiseControl:
<jabber host="my.network.local"
port="5222"
username="cruisecontrol"
password="cruisecontrol"
recipient="builds#conference.my.network.local"
chatroom="true"
buildresultsurl="http://cruise.control.net:7070/dashboard/tab/build/detail/customer" />
If I set chatroom to FALSE and enter a single recipient, everything works great. The problem I have is sending sending the build notification to a chat room. I set the chatroom value to TRUE and enter the fully qualified chatroom name I get the following error:
2009-10-16 13:34:10,818 [Thread-70897] ERROR JabberPublisher - Could not send message to recipient or chat room
No response from server.:
at org.jivesoftware.smack.GroupChat.join(GroupChat.java:162)
at org.jivesoftware.smack.GroupChat.join(GroupChat.java:123)
at net.sourceforge.cruisecontrol.publishers.JabberPublisher.init(JabberPublisher.java:146)
at net.sourceforge.cruisecontrol.publishers.JabberPublisher.publish(JabberPublisher.java:201)
at net.sourceforge.cruisecontrol.Project.publish(Project.java:742)
at net.sourceforge.cruisecontrol.Project.build(Project.java:264)
at net.sourceforge.cruisecontrol.Project.execute(Project.java:147)
at net.sourceforge.cruisecontrol.ProjectConfig.execute(ProjectConfig.java:402)
at net.sourceforge.cruisecontrol.ProjectWrapper.run(ProjectWrapper.java:69)
at java.lang.Thread.run(Thread.java:619)
Has anyone been able to send build messages to a Jabber chatroom using this method?
I haven't used Jabber with CruiseControl, but have you tried connecting to that port manually from your server running CC?
Like:
telnet my.network.local 5222
Can you log any of the xmpp / jabber packets from the client to server and back? We can see the CruiseControl config file and the java error, but we can't see what xmpp packets are actually being sent and received. That may be key in the troubleshooting.