Open Bug 1324394 Opened 8 years ago Updated 4 months ago

Allow origins to be edited in the Password Manager

Categories

(Firefox :: about:logins, enhancement, P3)

enhancement

Tracking

()

ASSIGNED

People

(Reporter: peter, Assigned: ssachdev)

References

(Depends on 3 open bugs)

Details

(Whiteboard: [fxcm-productive-ux])

Attachments

(3 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161213204721

Steps to reproduce:

1. Open a website (say https://secure.example.com), login and remember credentials
2. Revisit website. For some reason it always redirects to https://example.com now.
3. Open the Password Manager.
4. Search for the host example.com, find secure.example.com
5. Right-click on the row.


Actual results:

Only the "Edit username" and "Edit password" options are shown.


Expected results:

Additionally, the "Edit host" option should be available.
Severity: normal → enhancement
Component: Untriaged → Password Manager
Product: Firefox → Toolkit
Priority: -- → P3
Whiteboard: [passwords:management]
Component: Password Manager → about:logins
Product: Toolkit → Firefox
Version: 50 Branch → unspecified

Mass removing [skyline] and [passwords:management] from about:logins bugs which are no longer useful.

Whiteboard: [passwords:management]

Can I work to fix this bug ?

I wouldn't recommend it since it's unconfirmed how/if we want to do this since users could easily make edits that stop logins from being saved.

Summary: Allow hostname to be edited in the Password Manager → Allow origins to be edited in the Password Manager

(In reply to Matthew N. [:MattN] from comment #3)

I wouldn't recommend it since it's unconfirmed how/if we want to do this since users could easily make edits that stop logins from being saved.
Please do take into account that not all users are as "dumb" as suggested by this comment of yours.

In fact, I'd love to see this bug implemented to fix Firefox's wrong behavior of not recognizing that a login for "subdomain1.example.net" probably applies for "subdomain2.example.net" and/or even "example.net".
So, if @Rizwan S wants to fix this, I highly vote for letting him do so - previous bugs (back when GitHub issues were used instead of Bugzilla) suggested it should be implemented ASAP.

Can't edit my comment, so replying again with the correct comment content:

(In reply to Matthew N. [:MattN] from comment #3)

I wouldn't recommend it since it's unconfirmed how/if we want to do this since users could easily make edits that stop logins from being saved.

Please do take into account that not all users are as "dumb" as suggested by this comment of yours.

In fact, I'd love to see this bug implemented to fix Firefox's wrong behavior of not recognizing that a login for subdomain1.example.net probably applies for subdomain2.example.net and/or even example.net.
So, if Rizwan S (can't mention him via @Rizwan S, probably due to a Bugzilla bug) wants to fix this, I highly vote for letting him do so - previous bugs (back when GitHub issues were used instead of Bugzilla) suggested it should be implemented ASAP.

We were trying to make a simple password manager for mainstream users, not target the same market as third-party password managers with advanced UX and bells and whistles. Editing the origin can cause passwords to no longer fill and most people wouldn't need to do that so that's why we didn't do it yet. The other issue is that users cannot edit the formActionOrigin or httpRealm so editing the origin isn't necessarily going to fix their problems.

If there is good validation and the UX doesn't tempt users to edit it when they shouldn't then supporting this is fine but we'll need to figure out how to handle formActionOrigin and httpRealm too.

(In reply to Matthew N. [:MattN] from comment #3)

I wouldn't recommend it since it's unconfirmed how/if we want to do this since users could easily make edits that stop logins from being saved.

How could editing already saved logins “stop logins from being saved”? Did you mean stop logins filled out automatically?

You could add an extra option on top of the about:logins page where the user have to actively activate the ability to edit the URL, maybe with a warning shown that it might stop logins filled automatically

I reactivated an old router and gave it an IP address in the current IP net. When entering the login data, Firefox asked to update the stored login data. By that I recognized I used an IP address I already had in use for my second router. So now I would like to change the saved URL in about:logins. Please make this function available!

Please make website adress with URL or IP-address editable. Editing this field is no more "dangerous" for users than any if the other fields.

Since you can make a new login and enter the origin manually, I don't see a compelling reason not to allow editing the origin field of existing login items. You can already do this, just by a more convoluted series of steps: Make a new login with the preferred origin, enter the same password and username. Now delete the old login. Users who want to edit the origin of a login item will just end up doing this instead. Which is unfortunate, since this method is more tedious, requiring several more steps, and is more prone to errors. In the process of re-entering a username and password, there is a chance, however small, that the user enters the username/password wrong without realizing it, then deletes the old entry and loses the correct information. Since this process requires one to delete a login item, there's also the potential that the user will try to delete one login and end up accidentally deleting a different login. To just allow editing the origin field would reduce the risk of data loss, I think. I don't know anything about the logins page but I'll revisit this when I have some time to research it.

...Just my 2 cents...
I am unable to use PW manager for a specific site because that particular
site requires a specific URL suffix or it redirects to a different site

MADE UP EXAMPLE:
Firefox only allows " https://www.mysite.com"
I NEED URL to be " https://www.mysite.com/code22"

PW manager forbids use of any URL suffix ie: "/xxxxx"

Yeah this is definitely another reason it's important. I still use Bitwarden mainly because of redirects.

A command line work-around: I used sed to replace the old name of an internal server with the new one in a couple of files called logins.json that I found inside the .mozilla configuration directory using find. I restarted firefox and everything worked as expected.

(In reply to jorge.moraleda from comment #18)

A command line work-around: I used sed to replace the old name of an internal server with the new one in a couple of files called logins.json that I found inside the .mozilla configuration directory using find. I restarted firefox and everything worked as expected.

Just a bit of warning: this might not trigger sync properly, if you are using Firefox Account, you may have changes done only locally. We'll need to close bug 1752839 first to allow direct changes to logins.json.

Severity: normal → S3

In addition to this, I'd love for regex support on the edited URL.
In terms of collisions between regex entries and concrete entries, prioritize concrete entries.
Using lampoilman's example...

  1. Save "https://www.mysite.com"
  2. Edit it to be "https://www.mysite.com/code[0-9]{2}"
    Then it would work for all https://www.mysite.com/code00 -> https://www.mysite.com/code99, but not https://www.mysite.com/codeAA
Whiteboard: [fxcm-productive-ux]

How do we access the atlassian.net URL?

(In reply to John Veness from comment #32)

How do we access the atlassian.net URL?

Hey John, to my knowledge there is no way at the moment, sorry. It's an internal system used for sprints planning.

Flags: needinfo?(gisavom422)

I just wanted to put my two cents in.
I like how bitwarden allows for multiple uri fields
maybe that could be a solution? I mean we arent going to have app resource uri but it could be useful when a user has one account that spans multiple domains, Microsoft for example.

Restrict Comments: true
Assignee: nobody → ssachdev
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #9365737 - Attachment description: WIP: Bug 1324394 - Allow origins to be edited in about:logins. r=#credential-management-reviewers → Bug 1324394 - Allow origins to be edited in about:logins. r=#credential-management-reviewers
Flags: qe-verify+

Test setup:

  1. On desktop, navigate to about:logins
  2. Create a login entry for a website.
  3. Edit the login. Change the value of the “Website address” field to another website
  4. Save changes.

Test Scenarios (for Desktop/ iOS / Android) :

  • Verify that changes to the login’s website address persists on Firefox desktop/ iOS/ Android.
  • Verify that autofill no longer triggers for the old website.
  • Verify that autofill for new website triggers.
  • [Desktop only] If old website was breached, verify the alert is removed after changing the website value.

We finished testing on desktop, covering Windows 11, Ubuntu 20.04 and macOS 11.6.
We observed a couple of issues, I will mention them below and please let us know if we should log bugs for them.

In the video attached we discovered 2 issues:

  1. Entering a website address without https:// and pressing “Enter” key while in edit mode will show “Please enter a URL” error. If I press “tab” key and then “Enter” key the password is saved. Not a regression, it's also reproducible on the latest Nightly.
  2. Editing a website address and then trying to edit another website address will replace the website address with the previous one.

Another issue we observed that vulnerable passwords sign and notification aren’t being synced. Not a regression, it's also reproducible on the latest Nightly.

Thanks.

Flags: needinfo?(mtigley)
Attached image QA_Android.png

We’ve verified the above scenarios for Windows/Linux/Android and the expected results were obtained:

  • The modified login in Desktop/Linux was correctly synced and displayed updated on Android; when deleted from Desktop, the login was no longer displayed on Android;
  • On Android, the autofill prompt was not triggered for the old website;
  • On Android, the autofill prompt was correctly triggered for the updated website and autofill worked as expected;
  • Desktop, the warning icon displayed on the right side of the old login was removed after updating the login.

Tested using the received local builds on Desktop/Linux and the latest Fenix Nightly 123.0a1, Beta 122.0b7 and Release 121.0.1 builds on Android.

Tested with:

  • Google Pixel 8 Pro (Android 14)
  • Ubuntu 22.04 x64
  • Windows 10 x64

(In reply to Hani Yacoub, Desktop QA from comment #43)

Thank you Hani! Yes, please file those discovered issues discovered in separate bugs.

Flags: needinfo?(mtigley)

Validated the scenarios below using the following env:
FF versions: Windows (provided build), iOS v121.2 (37524)
Device: iPhone 14+ (16.0.3)

Scenarios:

  1. Create new Login on Windows; the data was correctly synced on iOS
  2. Update the login data on Windows (Website, username and password); the data was correctly synced on iOS
  3. Confirming that autofill no longer triggers for the old website. Using "open and fill" option from password details the updated website opens.
Depends on: 1874160, 1874170

(In reply to Hani Yacoub, Desktop QA from comment #43)

Another issue we observed that vulnerable passwords sign and notification aren’t being synced. Not a regression, it's also reproducible on the latest Nightly.

To clarify, do you mean if the user updates a breached/vulnerable login the notification is removed for the login currently updated but the notification still appears after syncing on another device?

I wasn't able to find a bug for this, did you happen to file a separate issue for it?

Flags: needinfo?(hyacoub)
Depends on: 1874397

I had difficulties yesterday to find some clear steps on how to reproduce the bug easily.
I managed today to log bug 1874397 for the vulnerable passwords issue.

No longer depends on: 1874397
Flags: needinfo?(hyacoub)
Depends on: 1874397
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: