2058449 - network.lna.skip-domains not working as expected

Status: UNCONFIRMED

(Core :: Networking, defect)

Description

[Andrew Ducker]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:153.0) Gecko/20100101 Firefox/153.0

Steps to reproduce:

We're using the GitLab Web IDE. It sends a request from {some kind of GUID}.cdn.web-ide.gitlab-static.net to gitlab.ourdomain.com. This was working until the latest Firefox vesion was installed.

This now shows up as a CORS error in the logs. It does not pop up a message box to ask if it should be allowed.

If I add gitlab.ourdomain.com to network.lna.skip-domains then it all works. Indicating that it's a Local Network Access issue rather than a CORS issue.

But we don't want to open up gitlab.ourdomain.com to all websites. So I tried adding *.cdn.web-ide.gitlab-static.net to network.lna.skip-domains instead - but this didn't have any effect.

Actual results:

1. No popup when trying to launch the IDE, just a CORS failure in the logs.

2. Adding the calling domain to network.lna.skip-domains did not enable the call to work. (But adding the called domain did enable it)

Expected results:

1. There should have been a popup.

2. The error shouldn't have been CORS, but something specific.

3. Failing this, adding the calling domain should have worked.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Kershaw Chang [:kershaw]]

Hi Sunil, could you take a look and triage this?
Thanks.

Comment 3

[Andrew Ducker]

For further info this is affecting numerous people in my office and seems to be spreading (presumably as it's rolled out).

Comment 4

[Sunil Mayya]

Hey Andrew, thanks for raising this issue.
If the request is getting blocked right away without prompting then this means the request is coming from insecure context or the request is coming from an iframe which is cross origin to the top level page and we have not defined permission delegation.

Can you please clarify the url of the top level page and the url that triggers the request to gitlab.ourdomain.com.
Feel free to remove any sensitive info from URL, I am only interested in the scheme, origin, domain info to confirm if they match my assumption.

Comment 5

[Bob]

It's a cross-origin iframe trying to communicate back to the original domain using an allow policy that works in Chrome but not Firefox.

The sequence roughly goes:

1. User loads IDE page under internal domain
2. Page adds iframe for extension isolation, pointing to external domain (with allow = local-network-access)
3. iframe script tries to communicate back to internal domain api, fails
4. Page reports an error loading IDE

(I can share an actual request log if necessary, though it'd be a bit of a pain to fully sanitise.)

---

GitLab WebIDE runs a web-hosted copy of VSCode with extensions that run under a separate domain for isolation. So, for example, you might have:

• gitlab.internal.example.com hosting the local GitLab instance, e.g. https://gitlab.internal.example.com/-/ide/project/some-project-slug/edit/master/-/README.md. This is the domain of the top-level page.
• A (random?) domain under *.cdn.web-ide.gitlab-static.net hosting untrusted extensions, e.g. https://workbench-83xxxxxxxxxxxxxxxxxxxxxx63.cdn.web-ide.gitlab-static.net. This is loaded inside an iframe.

This is a default configuration, and they do document ways to configure an internal domain for the same extensions, though this is not fully trivial to set up and maintain (you end up dealing with an additional domain + certificate + custom config).

The extension domain needs to be able to communicate back to the primary GitLab host via its api under https://gitlab.internal.example.com/api/graphql script is loaded under an iframe that requests the policy local-network-access:

iframe.setAttribute('allow', 'local-network-access');

This works fine in Chrome, with an additional LNA permissions prompt. In Firefox this reports in the console a Feature Policy: Skipping unsupported feature name “local-network-access”., presumably because this policy isn't supported in Firefox (assuming MDN is accurate). Then the CORS preflight to the API endpoint fails and WebIDE fails to load with a CORS error.

Comment 6

[Andrew Ducker]

Thanks Bob - that's exactly it. (Sorry for the delay, been on holiday for a week). Hopefully that's enough information for Sunil to get to the bottom of things.

Comment 7

[Chris Adams]

Thanks for posting that reduction — we confirmed that adding our GitLab server to network.lna.skip-domains resolves the issue. It wasn't clear whether this was true of everyone but in our case our GitLab server is hosted on an internal (RFC 1918) address whereas the working servers such as gitlab.com are, of course, using public domains, and that could explain why this hasn't gotten as much attention.