GNOME Bugzilla – Bug 624638
pdm-dialog: Rethink password management in epiphany
Last modified: 2013-12-11 11:59:29 UTC
Personal Data / Passwords is empty Yet, passwords and logins are filled in on certaim websites for instance mail.google.com Passwords and logins are still filled in after 1) Selecting Clear All.. and selecting Saved passwords. 2) rm -r ~/.gnome2/epiphany
Related to bug 620886.
*** Bug 620886 has been marked as a duplicate of this bug. ***
Created attachment 168254 [details] [review] pdm-dialog: correctly query the keyring passwords Passwords dialog was empty because GNOME Keyring doesn't consider our "network passwords" as such anymore, hence, our query is retrieving and empty set. Instead of relaying on the item type we filter based on what the item contains. Similar to what we do in embed/ephy-embed-single.c Bug #624638
I cannot reproduce this, so I think the assesment made in comment #3 cannot be completely correct. What's going on here?
(In reply to comment #4) > I cannot reproduce this, so I think the assesment made in comment #3 cannot be > completely correct. What's going on here? Well, that's interesting to know... I guess this means a few hours of checking out what the hell is wrong in gnome-keyring
I have the same problem - storing passwords works fine, but the list in Personal Data -> Passwords is empty. Version: 2.30.5 on Arch linux. Any ideas how to fix this?
I sometimes get an empty password list in the personal data.
Some of our users are also suffering this: http://bugs.gentoo.org/show_bug.cgi?id=359021 Personally, I cannot reproduce... but looks like password manager doesn't work ok always, sometimes I am unable to read passwords when setting it to show them, others I can see them without problems... :-/
Comment on attachment 168254 [details] [review] pdm-dialog: correctly query the keyring passwords Due to the libsecret migration this API would be obsolete, yet the patch could make sense to fix our not-associated passwords. See bug #685694 for the non association, and bug #679918 for the migration.
This might give some hints. The other day, after a reboot, I opened epiphany and the passwords window was empty. Then I opened chromium and when going to a site for which it had stored my password, it asked me for the gnome-keyring (I think) password. After this, I went back to ephy and checked the passwords window, which contained my passwords. I haven't tried to reproduce this again, but I could if necessary.
I'm seeing this bug now: the passwords tab is empty, even though I've saved at least one password in Epiphany (and it is visible in Seahorse). The situation persists even after I log out and log in again. I'm running Epiphany built from git master on Ubuntu 13.04.
In fact I'm also seeing an empty passwords tab on a Fedora machine running Epiphany 3.8.0. So maybe this is just plain broken right now.
(In reply to comment #12) > In fact I'm also seeing an empty passwords tab on a Fedora machine running > Epiphany 3.8.0. So maybe this is just plain broken right now. It's not, it works here (also Fedora 18), so I'm not sure of what's the issue. Is the password saving working at all? Since you say it shows up in Seahorse I assume it is. Any warning in console or anything, it would seem the code fetching the passwords from the keyring to show them in the PDM is broken in your case...
I see this problem on two machines. On both machines the Personal Data->Passwords tab is empty but passwords show up in Seahorse. On one machine (Fedora 19), Epiphany fills in saved passwords when I visit a web page, and on the other (Ubuntu 13.04) it doesn't. I have these library versions: Ubuntu 13.04: libsecret 0.15-0ubuntu1, gnome-keyring 3.7.92-0ubuntu1~raring1 Fedora 19: libsecret-0.15-1.fc19, gnome-keyring-3.8.0-1.fc19 Xan, what versions do you have?
Also, since you asked: I get no console warnings when I visit the Passwords tab or save a password.
Is it a HTTPS password or credentials in a form? Ephy is no longer showing the HTTPS passwords in the pdm-dialog.
I'm seeing this bug with various sites, all of which uses credentials in a form (on a page which is itself typically retrieved via HTTPS). In other words, these sites don't use HTTP authentication.
Actually it turns out I was running Epiphany 3.8.0 on Fedora 19 and git master on Ubuntu. 3.8.0 fills in saved passwords when I visit a web page, but git master does not (which is likely related to https://bugzilla.gnome.org/show_bug.cgi?id=666326#c8). Neither of these versions is showing saved passwords in Personal Data->Passwords.
(In reply to comment #10) > This might give some hints. > > The other day, after a reboot, I opened epiphany and the passwords window was > empty. Then I opened chromium and when going to a site for which it had stored > my password, it asked me for the gnome-keyring (I think) password. After this, > I went back to ephy and checked the passwords window, which contained my > passwords. > > I haven't tried to reproduce this again, but I could if necessary. I can reproduce this by logging out of my session and back in. Note this means that gdm is not unlocking my 'default' keyring, but in any case, ephy should unlock the locked keyring if needed (as chromium does).
(In reply to comment #11) > I'm seeing this bug now: the passwords tab is empty, even though I've saved at > least one password in Epiphany (and it is visible in Seahorse). I am having exactly this problem on 3.8.2, any suggestions for a work around? It's a bit difficult to document the passwords dialog if there aren't any passwords there :)
Same here: Epiphany 3.10.1.
Claudio explained to me that only HTTP-Auth passwords are stored in the Epiphany passwords dialog…
(In reply to comment #22) > Claudio explained to me that only HTTP-Auth passwords are stored in the > Epiphany passwords dialog… Why aren't these stored in the Gnome keyring as well, so that we can offload the entire stored passwords management to Seahorse?
(In reply to comment #23) > (In reply to comment #22) > > Claudio explained to me that only HTTP-Auth passwords are stored in the > > Epiphany passwords dialog… > > Why aren't these stored in the Gnome keyring as well, so that we can offload > the entire stored passwords management to Seahorse? They are stored in the keyring too. You can manage all of the ephy passwords in seahorse. We probably need to rethink how passwords are managed in ephy if we manage them at all.
Sorry, that was bad wording on my part. Show there, yes, but I don't know where they are stored (maybe in seahorse anyway?) and I have no way to test.
Claudio, from a documentation point of view, there would be less to document if they were only manageable through seahorse. On the other hand, it strikes me as slightly more user friendly if they can be managed through epiphany.
Seahorse is just a UI to manage secrets. The secrets are stored in a backend, which could be the gnome-keyring, for instance. We use libsecret (and so does Seahorse) to access the secrets. I believe that delegating secrets entirely on Seahorse is bad, particularly if we don't make it clear. People will always look for a way to manage their passwords from Ephy. But we can always instead make it possible to launch Seahorse from Epiphany if that's a good and consistent UX; we could also reuse some part of the Seahorse UI in Ephy; or rewrite this dialog with a renewed UI. I think we should aim to come up with the most consistent and user friendly experience first and then move from there.
(In reply to comment #27) > I believe that delegating secrets entirely on Seahorse is bad, particularly if > we don't make it clear. People will always look for a way to manage their > passwords from Ephy. But we can always instead make it possible to launch > Seahorse from Epiphany if that's a good and consistent UX; "Prior art" in this context is launching gedit from the Preferences to edit a user stylesheet.
*** This bug has been marked as a duplicate of bug 720239 ***