New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 364745 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner: ----
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Treat PSL matching consistently across all platforms

Project Member Reported by gcasto@chromium.org, Apr 18 2014

Issue description

This came up while investigating  issue 346210 . At the moment PasswordStore implementations that use LoginDatabase will have origin, signon_realm, and action overwritten so that if the PSL matched password is used it will trigger normally the second time (e.g. filled on page load). GNOME doesn't do this and KWallet hasn't been implemented yet. We should standardize how this works. I think that there is value to how the LoginDatabase implementation works, though it does cause sync errors at the moment that we need to deal with.
 

Comment 1 by gcasto@chromium.org, Apr 18 2014

Cc: vasi...@chromium.org
Actually, the GNOME way of doing things breaks sync in the other direction. Specifically PSL matches are saved via AddLogin() right now, and if we don't update signon_realm, etc. then we end up adding an entry that already exists.

[32313:32335:0418/103310:ERROR:generic_change_processor.cc(475)] Passwords Failed to create Passwords node: ActOnPasswordStoreChanges@../../components/password_manager/core/browser/password_syncable_service.cc:278, entry already exists

So either way we decide to standardize this we need to figure out the sync implications.

Comment 2 by vabr@chromium.org, Apr 19 2014

Thanks a lot for bringing this up!
In my personal opinion, the behaviour of Gnome is unexpected and broken: accepting a PSL suggestion should always result in saving an exact-origin-match copy of the password, and having it autofilled on the next visit.

I'm happy to take a stab at fixing this for Gnome, and getting it right for KDE (which I was planning to finally add support for). If Vasilii or someone else can take care of how to make this behaviour unbreak sync, that would be helpful.

Comment 3 by vabr@chromium.org, Apr 20 2014

One point to consider, though, if we store PSL-matched passwords as origin-matching copies:

If the user changes their password for www.example.com, and we update that, then the previously PSL-matched password for m.example.com would not be updated automatically.

I believe that's better than PSL-matching the m.example.com password each time, because that would stop password autofilling on every visit, whereas passwords are updated not that often.

We should watch out for PSL matched generated passwords though, if we allow updating them automatically.

Comment 4 by vabr@chromium.org, Apr 21 2014

https://codereview.chromium.org/245563005/ is in flight to make Gnome follow the LoginDatabase example.
Project Member

Comment 5 by bugdroid1@chromium.org, Apr 25 2014

Labels: merge-merged-git-svn
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c354e8f59b73f43ef7b6a3fb9fc731bfb3c953c1

commit c354e8f59b73f43ef7b6a3fb9fc731bfb3c953c1
Author: vabr@chromium.org <vabr@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Fri Apr 25 09:32:27 2014 +0000

Passwords PSL Matching on Gnome: overwrite realm and origin

On LoginDatabase using platforms, a password entry found by a PSL match gets the signon realm and the origin overwritten to match the query password form. This way, when the credential is saved, it is saved for the new site.

On Gnome, the overwriting did not happen. This CL introduces this to match the LoginDatabase behaviour.

Also, on Gnome, PSL matching was used not only to get logins, but also to check for existing logins when adding and updating passwords. The latter two use cases should require exact matching (that's also what happens in LoginDatabase). This CL fixes that, and only keeps PSL matching for GetLogins.

BUG= 364745 
R=gcasto@chromium.org

Review URL: https://codereview.chromium.org/245563005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@266177 0039d316-1c4b-4281-b951-d872f2087c98


Project Member

Comment 6 by bugdroid1@chromium.org, Apr 25 2014

------------------------------------------------------------------
r266177 | vabr@chromium.org | 2014-04-25T09:32:27.178061Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/native_backend_gnome_x_unittest.cc?r1=266177&r2=266176&pathrev=266177
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/native_backend_gnome_x.cc?r1=266177&r2=266176&pathrev=266177

Passwords PSL Matching on Gnome: overwrite realm and origin

On LoginDatabase using platforms, a password entry found by a PSL match gets the signon realm and the origin overwritten to match the query password form. This way, when the credential is saved, it is saved for the new site.

On Gnome, the overwriting did not happen. This CL introduces this to match the LoginDatabase behaviour.

Also, on Gnome, PSL matching was used not only to get logins, but also to check for existing logins when adding and updating passwords. The latter two use cases should require exact matching (that's also what happens in LoginDatabase). This CL fixes that, and only keeps PSL matching for GetLogins.

BUG= 364745 
R=gcasto@chromium.org

Review URL: https://codereview.chromium.org/245563005
-----------------------------------------------------------------

Comment 7 by vabr@chromium.org, May 31 2016

Status: Fixed (was: Untriaged)
Closing this as fixed, because PSL will not be implemented for KDE. Instead we'll drop the special backends and always use Login DB on Linux in the future: bug 571003.

Sign in to add a comment