Last Comment Bug 787046 - "Not authorized" error when connecting to an OpenFire XMPP server with the correct password.
: "Not authorized" error when connecting to an OpenFire XMPP server with the co...
Product: Thunderbird
Classification: Client Software
Component: Instant Messaging (show other bugs)
: Trunk
: All All
: -- normal (vote)
: Thunderbird 18.0
Assigned To: Florian Quèze [:florian] [:flo]
Depends on:
  Show dependency treegraph
Reported: 2012-08-30 06:40 PDT by Florian Quèze [:florian] [:flo]
Modified: 2013-02-16 12:48 PST (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

Patch (1.08 KB, patch)
2012-08-30 07:17 PDT, Florian Quèze [:florian] [:flo]
clokep: review+
standard8: approval‑comm‑aurora+
standard8: approval‑comm‑beta+
standard8: approval‑comm‑release+
Details | Diff | Splinter Review

Description Florian Quèze [:florian] [:flo] 2012-08-30 06:40:14 PDT
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:

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>]
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'/>
Comment 1 Florian Quèze [:florian] [:flo] 2012-08-30 07:17:54 PDT
Created attachment 656856 [details] [diff] [review]

We can work around it...
Comment 2 Patrick Cloke [:clokep] 2012-08-30 07:49:00 PDT
Comment on attachment 656856 [details] [diff] [review]

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?
Comment 3 aleth [:aleth] 2012-08-30 08:46:04 PDT
(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)?
Comment 4 Ludovic Hirlimann [:Usul] 2012-08-31 01:15:02 PDT
We should file a bug at Openfire yes.
Comment 5 Florian Quèze [:florian] [:flo] 2012-09-04 08:02:00 PDT
I added a reference to this bug in the comment (as requested in comment 2).
Comment 6 Patrick Cloke [:clokep] 2012-09-04 08:46:40 PDT
Was an upstream bug ever found or filed? (I had searched briefly myself, but didn't find one...)
Comment 7 Florian Quèze [:florian] [:flo] 2012-09-04 08:59:11 PDT
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 9 Mark Banner (:standard8, limited time in Dec) 2012-09-07 10:12:06 PDT
Comment on attachment 656856 [details] [diff] [review]

[Triage Comment]
We've agreed to take this forward for a 15.0.1.

Note You need to log in before you can comment on or make changes to this bug.