Two issues now: - the password prompt doesn't say that the username/password was bad, so it might be confusing. "How come it keeps popping up?!" (I've got some, um, "business users" who need the password problem to show in the UI)
- If I put in the correct password, it's not saved, so disconnect/reconnect fails. On 5/3/10 8:39 PM, "Evan Schoenberg, M.D." <[email protected]> wrote: > Joe, http://adiumx.cachefly.net/Adium_1.4b18.dmg should fully resolve this. > > Guys, I'll put a changelog up tomorrow evening and push the appcast for it. > If someone beats me to it, excellent. Consider this "rc1 except for 7 > tickets". > > Cheers, > Evan > > > On May 3, 2010, at 4:38 PM, Joe Hildebrand wrote: > >> Attached. Line to focus on: >> >> 15:35:58: <ESPurpleJabberAccount:385a9c0 2>:[email protected]: Disconnected >> ("SASL authentication failed"): Automatically reconnecting in 5.000000 >> seconds (0 attempts performed) >> >> >> >> On 5/3/10 3:03 PM, "Evan Schoenberg, M.D." <[email protected]> wrote: >> >>> >>> On May 3, 2010, at 3:49 PM, Joe Hildebrand wrote: >>> >>>> This *almost* works. The error is now correct, but we shouldn't >>>> auto-reconnect if the password was bad. >>> >>> I agree; however, code is already in place which should be handling that. >>> Please post debug logging of sending an incorrect password and not getting >>> prompted to enter a correct one. >>> >>> -Evan >>> >>>> >>>> >>>> On 5/3/10 2:30 PM, "Evan Schoenberg, M.D." <[email protected]> wrote: >>>> >>>>> >>>>> On May 3, 2010, at 11:42 AM, David Smith wrote: >>>>> >>>>>> I'd be happy to check if I can still connect to iChat Server if someone >>>>>> gives >>>>>> me a patched Adium. >>>>> >>>>> >>>>> I should have checked the code instead of the ticket; I left later-me some >>>>> good details there. >>>>> jabber_auth_start_cyrus() for us includes: >>>>> { >>>>> /* We have no mechs which can work. >>>>> * Try falling back on the old jabber:iq:auth method. We get here if the >>>>> server >>>>> supports >>>>> * one or more sasl mechs, we are compiled with cyrus-sasl support, but we >>>>> support or can connect with none of >>>>> * the offerred mechs. jabberd 2.0 w/ SASL and Apple's iChat Server 10.5 >>>>> both >>>>> handle and expect >>>>> * jabber:iq:auth in this situation. iChat Server in particular offers >>>>> SASL >>>>> GSSAPI by default, which is often >>>>> * not configured on the client side, and expects a fallback to >>>>> jabber:iq:auth >>>>> when it (predictably) fails. >>>>> * >>>>> * Note: xep-0078 points out that using jabber:iq:auth after a sasl failure >>>>> is >>>>> wrong. However, >>>>> * I believe this refers to actual authentication failure, not a simple >>>>> lack >>>>> of >>>>> concordant mechanisms. >>>>> * Doing otherwise means that simply compiling with SASL support renders >>>>> the >>>>> client unable to connect to servers >>>>> * which would connect without issue otherwise. -evands >>>>> */ >>>>> js->auth_mech = NULL; >>>>> jabber_auth_start_old(js); >>>>> return JABBER_SASL_STATE_CONTINUE; >>>>> } >>>>> >>>>> >>>>> However, elsewhere in auth_cyrus, jabber_cyrus_handle_failure() has what >>>>> appears to be better logic: >>>>> >>>>> if (tried_gssapi_first) { >>>>> /* If we tried GSSAPI first, it failed, and it was our only shot, try >>>>> jabber:iq:auth >>>>> * for compatibility with iChat 10.5 Server. >>>>> * >>>>> * iChat Server 10.5 offers SASL GSSAPI by default, which is often >>>>> * not configured on the client side, and expects a fallback to >>>>> jabber:iq:auth >>>>> when it (predictably) fails. >>>>> * >>>>> * Note: xep-0078 points out that using jabber:iq:auth after a sasl failure >>>>> is >>>>> wrong. However, >>>>> * I believe this refers to actual authentication failure, not a simple >>>>> lack >>>>> of >>>>> concordant mechanisms. >>>>> * Doing otherwise means that simply compiling with SASL support renders >>>>> the >>>>> client unable to connect to servers >>>>> * which would connect without issue otherwise. -evands >>>>> */ >>>>> sasl_dispose(&js->sasl); >>>>> js->sasl = NULL; >>>>> js->auth_mech = NULL; >>>>> jabber_auth_start_old(js); >>>>> return JABBER_SASL_STATE_CONTINUE; >>>>> } >>>>> >>>>> (comments expanded just-now by me). >>>>> In im.pigin.adium.1-4's 2fcd834324b05d3becf6878db8ce1c474578e720 I have >>>>> removed the former, aggressive behavior and left the latter. I think this >>>>> should solve the problem presented while maintaining the workaround for >>>>> iChat >>>>> Server 10.5's apparent wrongness. >>>>> >>>>> >>>>> This is committed in adium-1.4's >>>>> [6534647aece5289a0e5ac90c012bcbf75e3918f3]. >>>>> >>>>> A build for testing is uploaded at >>>>> http://adiumx.cachefly.net/Adium_1.4b18-noJabberHack.dmg >>>>> >>>>> The downgrade attack Joe mentions does still exist, but now if and only if >>>>> ((GSSAPI is the only offered SASL mech) && (GSSAPI fails)). Further >>>>> improvement would be a prompt as described in that setting; patches >>>>> welcome. >>>>> >>>>> Look forward to any feedback. >>>>> >>>>> -Evan >>>> >>>> -- >>>> Joe Hildebrand >>>> >>>> >>> >>> >> >> -- >> Joe Hildebrand >> >> <recon.log> > -- Joe Hildebrand
