Authentication Failure --> Re-Enable

[Daniel Atallah]

On Sat, Feb 13, 2010 at 13:58, Dan Mahoney, System Admin
<danm at prime.gushi.org> wrote:
> 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.

See http://www.pidgin.im/download/ubuntu/

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

AIM is not relevant - we're talking about XMPP here.
Trying to add all sorts of complicated workflow changes to detect
multiple failures isn't reasonable (also not a practical way to detect
a mistyped password) - if "issue number one" wasn't a problem, then we
wouldn't be having this conversation.

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

That is fine - a couple extra steps for a rare corner case is
perfectly acceptable - you're not going to routinely edit your account
and mistype your username.

> How about an "enable account now" checkbox in the "edit" dialog box, then?
> Or a "save and enable" next to the save? (Number 3).

Not necessary (see above).  Adding additional clutter to the
apparently already confusing dialog for something rare is not a good
idea.  Once again, "issue one" is the real problem that makes you want
this.

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

Perhaps the password field should be disabled when the "save password"
checkbox isn't checked.

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

Once again, for your issue this would not be a concern if the password
was cleared.

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

I only see two real issues ("In-memory password not cleared on auth.
failure" and "Password field is enabled, but doesn't do anything when
passwords aren't being saved") which are not related, so they should
be separate tickets.

-D