Opened 11 years ago

Last modified 9 years ago

#7654 new defect

Empty stream features cause pidgin to try non-sasl auth even after a successful sasl authentication

Reported by: roman Owned by: darkrain42
Milestone: Component: XMPP
Version: 2.5.2 Keywords:
Cc:

Description (last modified by datallah)

(21:38:06) jabber: Sending: <?xml version='1.0' ?>
(21:38:06) jabber: Sending: <stream:stream to='somedomain.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(21:38:06) jabber: Recv (289): <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='somedomain.com' id='8lPF88dNM' version='1.0'><stream:features><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>PLAIN</mechanism></mechanisms></stream:features>
(21:38:06) sasl: Mechs found: PLAIN 
(21:38:06) jabber: Sending: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN'>authwashere</auth>
(21:38:08) jabber: Recv (51): <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
(21:38:08) jabber: XML parser error for JabberStream 058771B0: Domain 1, code 5, level 3: Extra content at the end of the document

Change History (14)

comment:1 Changed 11 years ago by datallah

  • Component changed from unclassified to XMPP
  • Description modified (diff)
  • Status changed from new to pending

There isn't any error here (the "XML parser error" isn't an actual problem) - what is the problem you're experiencing?

Perhaps you just need to post more of the debug log.

Note that "PLAIN" certainly does work because that is what Google Talk uses.

comment:2 Changed 11 years ago by deryni

That debug log snippet is in fact a successful attempt at using PLAIN, the server responds with <success/> so you have actually authenticated correctly. So, as datallah asked, what exactly is the problem you are seeing? If it is just that extra content error that isn't an actual problem and can be safely ignored.

comment:3 Changed 11 years ago by roman

  • Status changed from pending to new

After that, this is what happens, the client initiates a new stream (http://xmpp.org/rfcs/rfc3920.html, section 6.5, step 10) and the server (being in the state with open session) sends the features:

(13:37:09) jabber: Recv (51): <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
(13:37:09) jabber: Sending: <stream:stream to='somedomain.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(13:37:09) jabber: Recv (149): <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='yKS1S4sWT' from='somedomain.com' version='1.0'><stream:features/>

in this state the client should consider itself "in" and request a roster, but now the weird thing happens, the client falls back to obsolete XEP-0065 authentication (I broke lines to make it readable):

(13:37:09) jabber: Sending: <iq type='get' id='purplea35f454f'>
<query xmlns='jabber:iq:auth'><username>someusername</username></query></iq>
(13:37:09) jabber: Recv (114): <iq type='result' id='purplea35f454f'>
<query xmlns='jabber:iq:auth'><username/><password/><resource/></query></iq>
(13:37:09) jabber: Sending: <iq type='set' id='purplea35f4550'>
<query xmlns='jabber:iq:auth'><username>someusername</username><resource>Home</resource><password>somepassword</password></query></iq>

Why is the "success" considered a XML parser error? Is the end of stream is expected?

comment:4 Changed 11 years ago by roman

Sorry, I mean XEP-0078

comment:5 Changed 11 years ago by roman

Hmm... I believe this is since the server doesn't advertise any features. I still think it's a bug, though really minor one, since the http://xmpp.org/rfcs/rfc3920.html#rfc.section.6.5 says that the features can be empty.

comment:6 Changed 11 years ago by deryni

  • Summary changed from Plain auth in XMPP doesn't seem to work to Empty stream features cause pidgin to try non-sasl auth even after a successful sasl authentication

The success message isn't an error, as we said ignore the xml error, it isn't material.

The issue here appears to be that the server is not requiring resource binding (something that is actually required for any normal usage of the connection to work) and pidgin is not handling this at all well.

Even if pidgin were to handle this better there wouldn't be anything for pidgin to do as it will not yet have bound a resource to the stream and as a result the server will be unable to route any messages to the connection (and in fact SHOULD return an error to any XML stanza pidgin would attempt to send). See section 7 of the rfc and section 8.1 of the bis draft of the rfc.

comment:7 Changed 10 years ago by lschiere

  • Owner lschiere deleted

comment:8 Changed 10 years ago by bernmeister

Based on deryni's comment, can/should this ticket be closed?

comment:9 Changed 10 years ago by darkrain42

  • Cc darkrain42 added

#11230 is the same issue. libpurple should probably handle this better, though I'd like to know what server this is.

comment:10 Changed 9 years ago by darkrain42

  • Owner set to darkrain42

comment:11 Changed 9 years ago by darkrain42

  • Status changed from new to pending

Roman, what server (and what server software) were you seeing this with?

comment:12 Changed 9 years ago by roman

  • Status changed from pending to new

This was a server I wrote :) However I still believe that I was following the specs.

comment:13 Changed 9 years ago by darkrain42

  • Status changed from new to pending

What exactly would you have Pidgin do in this situation? As deryni already said, the *only* thing that can happen at that point is resource binding, but your server isn't advertising resource binding, so Pidgin cannot proceed. Admittedly, Pidgin shouldn't be trying legacy non-SASL auth, but the alternative is simply to generate a connection error.

comment:14 Changed 9 years ago by roman

  • Status changed from pending to new

Yes, I believe that it should return an error in this case.

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!