Closed Bug 787046 Opened 12 years ago Closed 12 years ago

"Not authorized" error when connecting to an OpenFire XMPP server with the correct password.

Categories

(Thunderbird :: Instant Messaging, defect)

defect
Not set
normal

Tracking

(thunderbird15 fixed, thunderbird16 fixed, thunderbird17 fixed)

RESOLVED FIXED
Thunderbird 18.0
Tracking Status
thunderbird15 --- fixed
thunderbird16 --- fixed
thunderbird17 --- fixed

People

(Reporter: florian, Assigned: florian)

Details

Attachments

(1 file)

Paul sent me a log of a failed connection attempt to an OpenFire server (thanks!).

The auth sequence looks like this:
Client: <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="DIGEST-MD5"/>
Server: <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">[...]</challenge>
Client: <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">[...]</response>
Server: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl">[b64 encoded value containing: rspauth=<hex number>]</success>
At this point, Thunderbird marks the account as disconnected with "Not authorized" as the error.

The XMPP spec has an example of the expected exchange at: http://xmpp.org/rfcs/rfc3920.html#rfc.section.6.5

Instead of replying "<success ..." the server is expected to reply:
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
[b64 encoded value containing: rspauth=<hex number>]
</challenge>
And then the exchange finishes with:
Client: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Server: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Attached patch PatchSplinter Review
We can work around it...
Assignee: nobody → florian
Attachment #656856 - Flags: review?(clokep)
Comment on attachment 656856 [details] [diff] [review]
Patch

I hate putting in hacks for people that don't support specifications, but OpenFire is a pretty widely used server as far as I know.

Should the comment refer to this bug report, or do we think that comment is sufficient?
Attachment #656856 - Flags: review?(clokep) → review+
(In reply to Patrick Cloke [:clokep] from comment #2)
> Should the comment refer to this bug report, or do we think that comment is
> sufficient?
Or should it refer to an OpenFire bug (to be filed if it does not exist)?
We should file a bug at Openfire yes.
https://hg.mozilla.org/comm-central/rev/f170bb8998ce
I added a reference to this bug in the comment (as requested in comment 2).
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 18.0
Was an upstream bug ever found or filed? (I had searched briefly myself, but didn't find one...)
I couldn't find one either, but I found other people complaining about the same issue (especially a several years old Pidgin ticket that was closed as expired).
Comment on attachment 656856 [details] [diff] [review]
Patch

[Triage Comment]
We've agreed to take this forward for a 15.0.1.
Attachment #656856 - Flags: approval-comm-release+
Attachment #656856 - Flags: approval-comm-beta+
Attachment #656856 - Flags: approval-comm-aurora+
You need to log in before you can comment on or make changes to this bug.