Authentication Failure --> Re-Enable
Dan Mahoney, System Admin
danm at prime.gushi.org
Sat Feb 13 13:58:54 EST 2010
On Sat, 13 Feb 2010, Daniel Atallah wrote:
> On Fri, Feb 12, 2010 at 22:40, Dan Mahoney, System Admin
> <danm at prime.gushi.org> 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)
> You can (and should) try a newer version (but I don't believe this
> issue has been resolved).
This is the newest one in apt. I realize that sometimes ubuntu is slow
to track newer versions, instead opting to remain stable. (This is
laughable to me as I decided to try Karmic, which introduced a number of
regressions to me.) In turn, this is why I bring up the issue here rather
than open a bug immediately.
>> 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
> 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.
We'll call that option feature request number one. (Delete the stored pass
on an auth fail if it's not saved to disk).
The AIM case above is the only one I can think of (but then, I'm not a
protocol guru). I'd say the best logic might be: if I've gotten an
authfail, and I'm clicking "re-enable" and get ANOTHER auth-fail (while
trying the in-memory password), it's most likely that. (Feature request
>> 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.
Even if I had had something else wrong (say, my username), there'd still
be a need for the extra trip up to the enable menu once I had saved the
How about an "enable account now" checkbox in the "edit" dialog box, then?
Or a "save and enable" next to the save? (Number 3).
Also, there's an additional bug that's I may not have made clear from the
above. If, on the "edit account" button, I put a password, but do not opt
to save it, I am still prompted when I enable the account. This means
that the password field in the edit box means NOTHING unless you click
save. Logically, to me, it would mean "save this in memory and use for
sessions until I quit" but not to disk. (Bug #4)
The final bug is that in the current incarnation, there are both a "modify
account" and a "re-enable". I need BOTH, as things are currently set up,
but the dialog disappears after I hit modify. I'm still in a "failed"
state (I'm not signed in). The only reason I'd go to modify the account
is if I wanted to continue using it. Can we keep that dialog box around,
possibly add a little "x" or "dismiss" until I'm enabled? (Feature request
>> 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 (http://d.pidgin.im/newticket), there
> doesn't appear to be one already.
As above, it's actually four or five inter-related bugs. Would you (as
someone with more voice for the developers than I) prefer one issue per,
or one monolithic "this interaction all hurts my head, here's how to make
it better" bug?
-Bill & Ted's Bogus Journey
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
More information about the Support