Adium

Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#4627 closed defect (fixed)

After authentication failure, user is forced to type password on reconnect without option of using old one

Reported by: rdm@alum.mit.edu Owned by: evands
Milestone: Adium 1.2 Component: Adium Core
Version: Severity: normal
Keywords: Cc:
Patch Status:

Description

Most notably in AIM, if the connection/authentication fails for some reason (particularly due to heavy net traffic during initialization), AdiumX seems to remember this authentication failure, and subsequent attempts to connect generate a password prompt. Since the old password is NOT incorrect, if the user previously used the 'remember password' option before, there should be the option to 'use old password' without forcing the user to go find out what the password is and have to retype it in again by hand.

Attachments (1)

iChat.png (31.5 KB) - added by jhahn 13 years ago.
iChat dialog after authentication error

Download all attachments as: .zip

Change History (18)

comment:1 Changed 14 years ago by Eric Richie

Milestone: Needs feedback from users

What version of Adium are you using?

comment:2 in reply to:  1 Changed 14 years ago by rdm@…

Replying to edr1084:

What version of Adium are you using?

? I'm sorry, I was certain I had included that information in the original ticket, but it must have not made it in.

I was using AdiumX 0.89.1 under Mac OS X 10.3.9.

comment:3 Changed 14 years ago by Eric Richie

Version: 0.89

Try using the current AdiumBeta. You will probably find that this has been resolved but if not please let us know.

comment:4 Changed 14 years ago by Evan Schoenberg

This is not something that has changed since 0.89.

comment:5 Changed 14 years ago by Evan Schoenberg

If the password is wrong, it's wrong; we're not going to offer a "show password" type checkbox (as is seen when entering a password for an Airport network but nowhere else on the system). The real problem here is that a non-authenticated error should not be registered as an authentication failure; the error messages are certainly distinct.

comment:6 Changed 14 years ago by Eric Richie

Milestone: Needs feedback from usersNeeds Feedback - Received

comment:7 Changed 13 years ago by Jordan

Component: NoneAdium Core
Milestone: Needs Feedback - ReceivedNeeds feedback from users
Patch Status: None
Version: 0.891.0.3

I believe this is the same issue that occurs in #2093 - when a service fails to connect it appears to remove the password from keychain - whether an auth error or not. This one has more specific info to the topic.

Anyone who is able to consistently reproduce this, please try a build of adium that has the debug window enabled and attach your debug log here. One such build can be found here

comment:8 Changed 13 years ago by Jordan

comment:9 Changed 13 years ago by jhahn

I'm the (slightly devastated) author of the now-closed ticket #7021. Even if the server returns a definitive authentication error, it's not grounds for arbitrarily deleting a stored password. In my research, there's no precedent for ever purging a stored password from the Keychain in Apple apps or official IM clients, no matter what the server reports. (I've attached an image displaying iChat's behavior)

The solution to this problem is to remove the code responsible for forgetting passwords (more info at #7021) and replace it with a friendly dialog. I'd be happy to contribute code :)

Changed 13 years ago by jhahn

Attachment: iChat.png added

iChat dialog after authentication error

comment:10 Changed 13 years ago by Jordan

pending: 0
Resolution: worksforme
Status: newclosed

Since nobody seems interested in fixing this, and most others (including myself) believe that an authentication error is being correctly handled here, I'm closing this ticket. When someone has a working patch for this, either post it here and it will be re-opened or create a new ticket for it.

In my opinion, Adium has to trust the servers it relies upon - there are too many different services to try and pick through every single message and try and figure out it's deeper meaning... when it receives an authentication error it MUST be the case that your username/password is wrong - hence the deletion of the currently stored account... if it's wrong then you have to update it anyway! It makes perfect sense, and even if the server is wrong, there's no way for Adium to know that. If you feel otherwise, write a patch and attach it to a ticket.

comment:11 Changed 13 years ago by Ron Mabbitt

That's it? I wait a year for resolution, and people say, 'well, even though others have seen it, since the error hasn't happened to me, fix it yourself, I'm closing this'?

Bug trackers are for keeping track of open issues. Clearly, this IS an open issue. What I don't understand at all is that the obvious workaround (adding a button to retry the old id/password) is pretty trivial to add, solves the problem, and doesn't incovenience anyone in the (majority) cases where the id/password should be invalidated, since it simply won't work in those cases.

Ideally, Adium should figure out when either Adium or the server gets confused about invalidating the password -- but until then, why NOT implement the workaround?

And in any case, why close this ticket if the issue still is open?

comment:12 Changed 13 years ago by Evan Schoenberg

Milestone: Needs feedback from usersAdium X 1.2
Resolution: worksforme
Status: closedreopened

The real problem here is that there's absolutely no indication as to what the server said that made us show the password dialogue again; it's confusing and should be more informative. I'd like to look at this along with the other connection status issues (such as long-term reconnection attempts) for 1.2 or 1.3.

comment:13 Changed 13 years ago by Peter Hosey

We also should not forget the password from the Keychain just because the server said it was wrong. The servers have lied to us about that before, which makes that information untrustworthy, and we should never delete the user's data (in this case, a Keychain item) based on untrustworthy information. The only grounds to delete the password from the Keychain is deletion of the account from Adium.

comment:14 Changed 13 years ago by Terje Bless

Isn't the easy fix that fills all requirements here to simply prepopulate the reauth dialog with whatever was in the Keychain (regardless of what event triggered the reauth dialog)? If the account/passwd is actually wrong the user will have to type it in again, if it's correct and the server is just being wonky the user can hit return to try again with the existing info.

Notably, the Mac OS X login dialog behaves this way, so it should be expected behaviour for users.

comment:15 Changed 13 years ago by Evan Schoenberg

Owner: changed from nobody to Evan Schoenberg
Status: reopenednew

comment:16 Changed 13 years ago by Evan Schoenberg

Resolution: fixed
Status: newclosed

(In [21018]) Password errors now flag the account as needing to display a password window without removing the stored password from the keychain. The old password is prefilled in the password prompt window. Fixes #4627

comment:17 Changed 13 years ago by Evan Schoenberg

(In [21191]) Merged [21018]: Password errors now flag the account as needing to display a password window without removing the stored password from the keychain. The old password is prefilled in the password prompt window. Fixes #4627

Note: See TracTickets for help on using tickets.