Closed Bug 1726043 Opened 3 years ago Closed 3 years ago

Basic auth credentials cleared everyday / Daily call to purgeTrackingCookieJars ends up deleting active logins for unrelated websites

Categories

(Core :: Privacy: Anti-Tracking, defect, P1)

Firefox 91
defect

Tracking

()

RESOLVED DUPLICATE of bug 1721084

People

(Reporter: jean, Assigned: pbz)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Steps to reproduce:

  • Load a page protected by basic auth / htpasswd
  • wait for midnight GMT to pass (time at which purgeTrackingCookieJars is called)
  • interact with the page protected by basic auth

Actual results:

At that point a login prompt will pop up.

(I tested this with transmission bt client web interface and a simple html page with a few line of javascript that fetches itself every few second. after "midnight", the basic auth login prompt appears, everyday)

Expected results:

Basic auth credentials should not expire arbitrarily. Or at least if they do expire and that is expected behavior, it should documented somewhere.

What happens is that everyday purgeTrackingCookieJars is called to do tracker cookie cleanup.
If there is work to do, the following code is run:

    logger.log("Deleting data from:", origin);

    await new Promise(resolve => {
      Services.clearData.deleteDataFromPrincipal(
        principal,
        false,
        Ci.nsIClearDataService.CLEAR_ALL_CACHES |
          Ci.nsIClearDataService.CLEAR_COOKIES |
          Ci.nsIClearDataService.CLEAR_DOM_STORAGES |
          Ci.nsIClearDataService.CLEAR_SECURITY_SETTINGS |
          Ci.nsIClearDataService.CLEAR_EME |
          Ci.nsIClearDataService.CLEAR_MEDIA_DEVICES |
          Ci.nsIClearDataService.CLEAR_STORAGE_ACCESS |
          Ci.nsIClearDataService.CLEAR_AUTH_TOKENS |
          Ci.nsIClearDataService.CLEAR_AUTH_CACHE,
        resolve
      );
    });
    logger.log(`Data deleted from:`, origin);

(at this point principal contains the info related to the domain for which the data is being cleared.)

This ends up calling AuthCacheCleaner.deleteByPrincipal which is quite simple:

const AuthCacheCleaner = {
  deleteByPrincipal(aPrincipal) {
    return this.deleteAll();
  },

  deleteByBaseDomain(aBaseDomain) {
    return this.deleteAll();
  },

  deleteAll() {
    return new Promise(aResolve => {
      Services.obs.notifyObservers(null, "net:clear-active-logins");
      aResolve();
    });
  },
};

It sends a message to clear all active logins (nothing related to the current principal) and thus the active login for the basic auth page is cleared.

The above can be reproduced manually by:

  • logging in to a site with basic auth
  • opening the browser console and:
principals = this.Services.perms.getAllWithTypePrefix("storageAccessAPI")
principal = principals[0].principal   // or choose whichever you want to test, it really doesn't matter

await new Promise(resolve => {
      Services.clearData.deleteDataFromPrincipal(
        principal,
        false,
        Ci.nsIClearDataService.CLEAR_ALL_CACHES |
          Ci.nsIClearDataService.CLEAR_COOKIES |
          Ci.nsIClearDataService.CLEAR_DOM_STORAGES |
          Ci.nsIClearDataService.CLEAR_SECURITY_SETTINGS |
          Ci.nsIClearDataService.CLEAR_EME |
          Ci.nsIClearDataService.CLEAR_MEDIA_DEVICES |
          Ci.nsIClearDataService.CLEAR_STORAGE_ACCESS |
          Ci.nsIClearDataService.CLEAR_AUTH_TOKENS |
          Ci.nsIClearDataService.CLEAR_AUTH_CACHE,
        resolve
      );
    });


// it is also possible to only use the Ci.nsIClearDataService.CLEAR_AUTH_CACHE flag to test

And then observe that you're logged out of the basic auth page (the login prompt appears)

The Bugbug bot thinks this bug should belong to the 'Toolkit::Password Manager' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Password Manager
Product: Firefox → Toolkit
Component: Password Manager → Privacy: Anti-Tracking
Product: Toolkit → Core

This will happen once Firefox clears tracking cookie jars. To resolve this issue, I think we need to clear HTTP auth in a precise manner, that is only clearing data for the given principal.

Assignee: nobody → jhofmann
Severity: -- → S2
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P1

Bug 1721084 is another symptom of the same issue.

See Also: → 1721084
Assignee: jhofmann → pbz
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.