Authentication Failure --> Re-Enable

Daniel Atallah datallah at
Sat Feb 13 13:17:40 EST 2010

On Fri, Feb 12, 2010 at 22:40, Dan Mahoney, System Admin
<danm at> wrote:
> Hey there, I'm noticing an odd behavior with pidgin under ubuntu linux
> (whatever version just happens to come with Karmic via apt).  In this case
> it's Pidgin 2.6.2
> (libpurple 2.6.2)
> 95470d310d5d3a229c0b9fc4232da9bfeafaeb5b

You can (and should) try a newer version (but I don't believe this
issue has been resolved).

> As we all know, and as is an FAQ, pidgin leaves your password laying around
> in cleartext.  I currently don't have my password to the company jabber
> saved.  Instead, I have to type it at login.  I'm fine with this.
> As it's a good, complex password, I occasionally mistype it.
> I then get a note at the bottom of my buddy list:
> dmahoney at disabled
> Authentication failure
> [Modify Account][Re-Enable]
> Clicking re-enable simply tries the same password you've put in, again. It
> does not re-prompt you.  Presumably the only use for the "re-enable button"
> is if there's something that was broken on the server but is now fixed, or
> if pidgin has cached a password that you're *about* to change your password
> to.  (It's also useful with AIM as this is the error AIM hands you when you
> use the "disconnect all but the current connection" option).
> Once you're here, your only option is to "Modify" the account, and save it
> (still with no password).  Once you do that it dismisses the alert at the
> bottom of your buddy list, so you must THEN go back into
> accounts-->accountname-->enable and put in your password.
> An important note here is even if you put a password in, and click save, you
> have to go to the accounts menu, enable, and type your password again. It
> seems more logical that putting in a password would save it for THAT
> session, but not in the config file, but this does not appear to be the
> case.
> Would it not make more sense, on an auth fail, to have the system DELETE the
> in-memory password (if it's not saved on disk), so you'll simply be
> re-prompted?

Yes, I believe that would make sense.  I believe the complication is
that we can't necessarily tell that the problem is definitively that
you typed the password wrong - there are other cases under which a
"<not-authorized/>" may be received.

> Would it also not make sense that if I'm editing an account that was ONLY
> disabled for an auth fail, that as soon as I click save, it's re-enabled
> without having to manually do so?

That would require otherwise unnecessary accounting of the reason for
disabling, so I'd be inclined to say "not worth the effort" for an
exception case.  If the other issue (which I consider a bug) wasn't
present this would be a non-issue.

> Is there already a bug open on this issue?  I get this on two different
> machines, and it seems REALLY bad ui design.

It is more of a bug than bad design.

Feel free to file a ticket (, there
doesn't appear to be one already.


More information about the Support mailing list