Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make it possible to assign contextualIdentity's to the review tools doing page scraping #8

Open
hcs64 opened this issue Oct 17, 2018 · 7 comments
Labels
enhancement New feature or request

Comments

@hcs64
Copy link

hcs64 commented Oct 17, 2018

As a paranoia/defense-in-depth measure, I have my Bugzilla and Phabricator accounts logged in only in an account container. Since Phabricator support moved to scraping a logged in page, it isn't working for me, I suspect due to it only being able to access an uncontained Phabricator login (as it works when I log in outside of a container).

Just a note for the backlog...

@mikeconley
Copy link
Owner

Interesting - I hadn't considered that case. It looks like there's a contextualIdentities API which can resolve to a cookie store, so perhaps we can add an option for a user to assign a contextualIdentity for each review tool.

@mikeconley mikeconley changed the title No way to access Phabricator login in a container Make it possible to assign contextualIdentity's to the review tools doing page scraping Oct 17, 2018
@mozfreddyb
Copy link

Maybe the extension could take it one further and figure out which containers are assigned to those sites and use that identity for scraping?

@hcs64
Copy link
Author

hcs64 commented Oct 23, 2018

I got partway into implementing this, but ran into trouble when actually trying to use the cookies (since I can't read the HttpOnly values, nor set cookies programmatically). It should be possible to create a tab with the cookieStoreId and do the fetch() from a content script running there, but it seems like it would be a bit irritating to have the tab pop up. I might use a hidden tab but it sounds like there's UI around prompting the user to hide the tab.

The following works at least for detecting the cookie (must include the contextualIdentities permission):

const MULTI_ACCOUNT_CONTAINERS_EXTENSION_ID = "@testpilot-containers";

  async getCookieFromContainer(url, cookieName) {
    let assignment = await browser.runtime.sendMessage(
      MULTI_ACCOUNT_CONTAINERS_EXTENSION_ID,
      {
        url,
        method: "getAssignment",
      },
      {},
    );

    if (assignment && "userContextId" in assignment) {
      let cookieStoreId = "firefox-container-" + String(assignment.userContextId);
      return await browser.cookies.get({
        url,
        name: cookieName,
        storeId: cookieStoreId,
      });
    }
    return null;
  },

@hcs64
Copy link
Author

hcs64 commented Oct 23, 2018

Well, here's one terrible way to do it, adding a temporary web request rewriter to set the cookies: agashlin@a48db7f

Though this neatly bypasses all the other stuff containers provide.

@mikeconley mikeconley added the enhancement New feature or request label Oct 24, 2018
@mikeconley
Copy link
Owner

I think I'll need this bug fixed in Gecko if we're going to do this properly.

@mikeconley
Copy link
Owner

Looks like the Gecko dependency is being fixed. I'll come back around to this when I get a few few hours.

@mikeconley
Copy link
Owner

I looked at this today, and it turns out that this bug wasn't enough. :( That bug allows WebExtensions to intercept network requests and get information about the contextual identity that they're using... but as far as I can tell, there's no way to initiate a network request with a particular contextual identity without actually opening a tab / window to do it.

I'm basically hitting the same issue that @hcs64 ran into.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants