After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 643690 - Have to enter password even if provided during account creation
Have to enter password even if provided during account creation
Status: RESOLVED FIXED
Product: empathy
Classification: Core
Component: Accounts
2.33.x
Other Linux
: Normal major
: ---
Assigned To: empathy-maint
Depends on:
Blocks:
 
 
Reported: 2011-03-02 17:17 UTC by Omer Akram
Modified: 2011-08-29 10:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/password-643690 (729 bytes, patch)
2011-03-16 13:08 UTC, Guillaume Desmottes
accepted-commit_now Details | Review

Description Omer Akram 2011-03-02 17:17:22 UTC
using empathy 2.33.2 when you add a gtalk account and also add the password during creation and try to login empathy does not login and asks you to input the password in the new window. 

origin: https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/726920
Comment 1 Guillaume Desmottes 2011-03-04 10:30:25 UTC
Indeed I can reproduce this.
Comment 2 Guillaume Desmottes 2011-03-04 11:06:29 UTC
We don't store the password when creating a new account, so the auth-client can't find it and so ask for it when connecting.

An easy way to solve this would be to store the password in the keyring before starting to connect but that means we may save a wrong password in the keyring (I think that's fine; we already do that when the user changes the password field from the accounts dialog).

But that also means that we'll have to store the password even if the user didn't choose "remember password" (if not the auth-client will still ask for it) which is pretty annoying.

Actually I'm starting to wonder if being able to put the password in the accounts-dialog is a so good idea. Not displaying it at all and let the auth-client does the password asking and remembering would solve this.
We could still have a "Forget password" button in the accounts dialog to forget the pass of existing accounts.

Thoughts?
Comment 3 Guillaume Desmottes 2011-03-04 11:38:32 UTC
After some discussion with Sjoerd, we agreed that the proper way to solve this is to use an Observer in empathy-accounts that would provide the password when needed. That way it will work for accounts having MaySaveResponse=False as well.
Comment 4 Danielle Madeley 2011-03-14 04:39:08 UTC
Be aware when using an Observer that if there's a password in the keyring, there will be a race between empathy-accounts and empathy-auth-client.

This could be solved by flushing any passwords from the keyring when the user unchecks remember password and immediately saving a new password when it's changed (when remember-passed == TRUE). Or perhaps checking the keyring for a password to be the first stage of empathy-auth-client's Handler (which is probably where it should be?)
Comment 5 Guillaume Desmottes 2011-03-16 13:08:46 UTC
Created attachment 183535 [details] [review]
http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/password-643690

 libempathy/empathy-account-settings.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)
Comment 6 Sjoerd Simons 2011-03-17 07:21:11 UTC
Review of attachment 183535 [details] [review]:

looks good
Comment 7 Danielle Madeley 2011-03-17 07:31:17 UTC
Does this take into consideration MaySavePassword ?
Comment 8 Guillaume Desmottes 2011-03-17 09:10:45 UTC
No.
MaySaveResponse [1] is a property on the SASL channel, but we don't have such channel when the account has just be created (we have to connect). Maybe this property should be exposed on the Account object as well?

[1] http://telepathy.freedesktop.org/spec/Channel_Interface_SASL_Authentication.html#Property:MaySaveResponse
Comment 9 Danielle Madeley 2011-03-17 09:51:38 UTC
Possibly this could go on the Protocol object. Or we could immediately remove the saved password again in ServerSaslHandler if MaySavePassword is false.
Comment 10 Guillaume Desmottes 2011-03-17 13:55:02 UTC
Fixed in master and 2.34.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.