Adium

Ticket #8680 (closed defect: fixed)

Opened 1 year ago

Last modified 11 months ago

adium not trying gssapi?

Reported by: raeburn Assigned to: nobody
Priority: normal Milestone: Adium 1.2
Component: Jabber/XMPP Version: 1.2b5
Severity: regression Keywords: gssapi
Cc: Patch: None
Pending: 0

Description (Last modified by evands)

I've got an account on a server that supports GSSAPI (Kerberos 5) authentication, but also accepts passwords. After updating from 1.1.x to 1.2b5, it still insists on me entering a password. According to the log: 

16:23:12: (Libpurple: util) Writing file /Users/raeburn/Library/Application Support/Adium 2.0/Users/Default/libpurple/blist.xml
16:24:01: <ESPurpleJabberAccount:840a990 11>:raeburn@mit.edu: Updating status for key: Online
16:24:01: <ESPurpleJabberAccount:840a990 11>:raeburn@mit.edu: Updating status for key: StatusState
[ ... THIS is when it prompts me for my password, without having even connected yet ... ]
16:24:09: <ESPurpleJabberAccount:840a990 11>:raeburn@mit.edu: Updating status for key: User Icon
16:24:09: Adium: Connect: raeburn@mit.edu initiating connection using status state <AIStatus: 5f6320 [Available]> ((null)).
[ ... later ... ]
16:24:10: (Libpurple: jabber) Recv (410): <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="mit.edu" id="28ce58f8" xml:lang="en" version="1.0"><stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>GSSAPI</mechanism><mechanism>PLAIN</mechanism></mechanisms></stream:features>

If I hit "cancel" or "OK" (without a password) at the password prompt, it stops trying to log me in. If I enter an incorrect password, my login attempt fails. I don't see an option in the GUI for "(don't) require password" or "use SASL (or GSSAPI)".

I've also tried creating a new account on my machine, launching Adium in it as a new user, and connecting to my Jabber account, with no better results.

Attachments

adium-debug-log (6.6 kB) - added by raeburn on 12/27/2007 04:46:38 PM.
adium debug log (cut and pasted from debug window)

Change History

12/27/2007 04:46:38 PM changed by raeburn

  • attachment adium-debug-log added.

adium debug log (cut and pasted from debug window)

12/27/2007 05:17:00 PM changed by raeburn

client machine is running mac os x 10.4.11, if it matters

12/27/2007 10:11:36 PM changed by evands

  • description changed.

WikiFormatting

12/27/2007 10:14:11 PM changed by evands

  • severity changed from normal to regression.
  • milestone set to Adium X 1.2.

Ah, I wondered if this would happen. The password issue is awkward, but the real problem here is that the hack that is in place to allow PLAIN login to work on 10.4 actually ends up preferring PLAIN (or DIGEST-MD5) to any other mechanism if one is offerred (on 10.4 only). If the server didn't offer PLAIN, you'd find that the GSSAPI was used... and no, you shouldn't have to enter a password for that, and the password you do enter would be ignored, but that's a separate problem.

12/27/2007 10:50:18 PM changed by evands

(In [22025]) * Improved the hack we use to avoid PLAIN auth on 10.4 to still respect the mechanism list, only intervening if SASL determines that PLAIN is the best auth method. Decreased the delta for the hack significantly in the process. Refs #8680

  • Cleaned up and commented upon the other patches we're applying, pulling them directly from monotone.

12/27/2007 10:52:31 PM changed by evands

  • status changed from new to closed.
  • resolution set to fixed.

(In [22026]) libpurple 2.3.1 using the patches as modified in [22025], which should fix connectivity to servers which offer PLAIN but not as the preferred mech when connecting on 10.4. Fixes #8680. Note that Jabber still thinks it requires a password, so a UI bug mentioned therein still exists; entering any random non-zero-length string of characters for a password should let GSSAPI do its thing.

12/27/2007 11:42:57 PM changed by evands

(In [22030]) Added -[AIService supportsPassword] which determines if the service should display password fields at all and changed -[AIService requiresPassword] to determine whether it should insist upon a password before continuing the connect process. This allows Jabber and IRC accounts to be password-optional. Fixes the spurious password prompts for Jabber accounts which will be using GSSAPI, fixing the issue described as a side comment in #8680. Refs #8680.

01/01/2008 06:58:16 AM changed by raeburn

As of 1.2b7 it seems to be trying GSSAPI on Tiger, yay. I can sign on to a test server at work without a password now. However, I can't get onto our production server. My investigation indicates that it's trying to acquire Kerberos credentials to authenticate to the xmpp service on the host named in the user account, rather than the host being connected to. (E.g., for foo@example.com with a SRV record pointing to jabber.example.com, it would try to authenticate to the principal xmpp/example.com when I'm told it probably should be using xmpp/jabber.example.com. I'm not too familiar with the xmpp specs myself, and I think they made the wrong choice here, but there it is.) I'm trying to look into why that is...

Looking at jabber.c, it appears that srv_resolved_cb when called with non-null "results" passes the server's actual hostname in as the fqdn argument to be saved by jabber_login_connect, which seems to do the right thing. (And if there's no SRV record, it passes the user-supplied domain, which in that case would also be the right thing.) However, if I've configured the server name to connect to, then jabber_login passes the domain part of my user id as the fqdn, and that doesn't work.

Once I get a working setup where I can build and use a new libpurple, I'll try to produce a patch.

One of my co-workers also tells me that because our production server is running a version of Openfire before 3.4.2, it has a bug:

if the client doesn't specify an "authz name", the server will reject with an authorization failure.

If I remove the server hostname from my account configuration, I seem to run into this bug. While it might or might not be worth tweaking libpurple to side-step the problem, depending how easy that is, the current behavior of adium when encountering the bug is definitely a problem. I get prompted for a password, and if I click "cancel", I get prompted again. And again. And again....

01/02/2008 01:12:26 AM changed by evands

(In [22091]) AIPasswordPromptController now expects a selector which includes a returnCode to indicate whether OK or Cancel was pressed, which is needed now that an empty password is potentially valid (for a service on which a password is optional: Jabber or IRC).

Previously, hitting cancel on the password dialogue would continue the connect process for those services. Refs #8680 where this bad behavior was pointed out by raeburn.