Authentication Failure --> Re-Enable

[Dan Mahoney, System Admin]

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)
>> 95470d310d5d3a229c0b9fc4232da9bfeafaeb5b
>
> 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
>> 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.

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 
number 2).

>> 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 
thing.

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 
#5)

>> 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?

-Dan

-- 

"Station!"

-Bill & Ted's Bogus Journey

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------