Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#6635 closed patch (fixed)

XMPP registration fails

Reported by: Schuk Owned by: deryni
Milestone: 2.5.5 Component: XMPP
Version: 2.4.3 Keywords:
Cc:

Description

If I try to register a new account of "test@ example.com" at a Openfire 3.5.2 XMPP Server, I receive the error "400: Bad request". Pidgin trys to address the wrong recipient "jabber.example.com". "example.com" has an SRV entry to "jabber.example.com". "jabber.example.com" should not be addressed as this is the Domain where traffic is received and not the hostname of the jabber service. For example there will never be an account called "test@ jabber.example.com". See 4.4 "to" at http://www.xmpp.org/rfcs/rfc3920.html

Openfire Warn.log:

2008.08.19 22:24:40 User tried to authenticate with this server using an unknown receipient:
<iq type="set" id="purple49a3b578" to="jabber.example.com" from="example.com/3af8463">
<query xmlns="jabber:iq:register">
<username>test</username>
<password>test</password>
<name>test</name>
<email/>
</query>
</iq> 

Pidgin Debug:

(22:24:40) jabber: Sending (ssl): <iq type='set' id='purple49a3b578' to='jabber.example.com'><query xmlns='jabber:iq:register'><username>test</username><password>test</password><name>test</name><email/></query></iq>
(22:24:40) jabber: Recv (ssl)(302): <iq type="error" id="purple49a3b578" from="jabber.example.com" to="example.com/3af8463"><query xmlns="jabber:iq:register"><username>test</username><password>test</password><name>test</name><email/></query><error code="400" type="modify"><bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>

Previously sent XML Packets are addressed correct and get a proper response:

Pidgin Debug:

(22:24:02) jabber: Sending (ssl): <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(22:24:02) jabber: Recv (ssl)(573): <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="example.com" id="3af8463" xml:lang="en" version="1.0"><stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</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>
(22:24:02) jabber: Sending (ssl): <iq type='get' id='purple49a3b577'><query xmlns='jabber:iq:register'/></iq>
(22:24:02) jabber: Recv (ssl)(613): <iq type="result" id="purple49a3b577"><query xmlns="jabber:iq:register"><username/><password/><email/><name/><x xmlns="jabber:x:data" type="form"><title>XMPP Client Registration</title><instructions>Please provide the following information</instructions><field var="FORM_TYPE" type="hidden"><value>jabber:iq:register</value></field><field label="Username" var="username" type="text-single"><required/></field><field label="Full name" var="name" type="text-single"/><field label="Email" var="email" type="text-single"/><field label="Password" var="password" type="text-private"><required/></field></x></query></iq>

Regards, Thomas

Attachments (4)

xmpp_registration.patch (770 bytes) - added by niess 10 years ago.
appropriate-patch (811 bytes) - added by darkrain42 10 years ago.
appropriate-patch.2 (821 bytes) - added by darkrain42 10 years ago.
(patch that actually compiles, this time)
use-no-to.patch (3.7 KB) - added by darkrain42 10 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 11 years ago by deryni

I think the cause of this problem is the 'recent' changes to the handling of connect servers and the like to fix some of the single-sign on/SASL/etc. authentication stuff. I think the simplest answer here is just to not set the to attribute on the iq:register stanza but I need to verify that that is in fact going to work correctly, and is a valid thing to do.

comment:2 Changed 10 years ago by niess

This is still an open bug for Openfire and I think it should also be a bug for other server which accept only messages for their XMPP domain from local users. According to the XMPP RFC it's okay that the xmpp domain hosted by a server isn't the FQDN of the server since DNS SRV records have to be checked. According to the examples of XEP-0077 it's also valid to send the registration without a 'to' attribute. Is someone working on that or thinks this bug is an Openfire bug?

Changed 10 years ago by niess

comment:3 Changed 10 years ago by niess

The attached patch remove the 'to' attribute in the registration IQ stanza.

Changed 10 years ago by darkrain42

comment:4 Changed 10 years ago by darkrain42

Deryni, my attached patch adjusts the registration from address to be, if it's not set in the received stanza, the bare domain name we're connecting to, instead of the FQDN of the server.

This preserves the logic that we can either register to a specific domain (i.e. a transport or other component service) or register to set up our account (the situation that seems to be failing here). Removing the 'to' attribute would simply break component registration (Adium uses it).

Changed 10 years ago by darkrain42

(patch that actually compiles, this time)

comment:5 Changed 10 years ago by darkrain42

(or I could read my email before attaching patches... heh.)

comment:6 Changed 10 years ago by niess

Hi darkrain42, your patch works great and is a better solution for this bug. Thanks!

comment:7 Changed 10 years ago by deryni

I'm not actually sure we need to be sending a from at all when we want our server to handle it for us. I think we might be better served by simply not including a to attribute on the outgoing stanza when we didn't receive one. I don't believe that can break anything that isn't already broken and will prevent problems like this from happening as well as fixing our domain assumption seems to.

Changed 10 years ago by darkrain42

comment:8 Changed 10 years ago by darkrain42

niess, would you try the attached patch and make sure it still works?

comment:9 Changed 10 years ago by niess

it works ;-)

comment:10 Changed 10 years ago by rekkanoryo

  • Type changed from defect to patch

comment:11 Changed 10 years ago by rekkanoryo

  • Milestone set to 2.5.5
  • Resolution set to fixed
  • Status changed from new to closed

I committed 'use-no-to.patch' in ff7369e151932e20c318abd10759b3a18ef1e3de but am still wondering if we should be considering darkrain42's appropriate-patch.2 as well.

comment:12 follow-up: Changed 10 years ago by niess

First thank you for committing the patch. Either 'appropriate-patch.2' or 'use-no-to.patch' fix the described bug. In my opinion the 'use-no-to.patch' is the better solution.

comment:13 in reply to: ↑ 12 Changed 10 years ago by darkrain42

Replying to niess:

First thank you for committing the patch. Either 'appropriate-patch.2' or 'use-no-to.patch' fix the described bug. In my opinion the 'use-no-to.patch' is the better solution.

Agreed; rekkanoryo: I finally looked closely at the two patches and refreshed my memory: appropriate-patch.2 isn't necessary because that flawed use of serverFQDN is removed in the applied patch.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!