Cypress fails if ProxyMode Chrome policy is present

[dschulten]

Current behavior:

Tests running in Browser fail to connect to Cypress,io's reverse proxy if the ProxyMode Chrome policy is present, which blocks access to the proxy settings.

While a local admin can delete the ProxyMode policy, central administration can overrule that and insert it back after a few minutes, even if the local admin takes ownership of the Chrome registry node and forbids access to anyone.

A possible workaround is to switch to Electron using the Browser dropdown on the right hand side of the Cypress application window (which says Chrome XX while using Chrome).

Desired behavior:

Tests should run. Cypress should possibly handle situations where a ProxyMode policy is in place.

How to reproduce:

Create a policy key _HKLM\Software\Policies\Google\Chrome_, create a value ProxyMode of type REG_SZ inside the _Chrome_ key and set it to system.

That will make it impossible for users to edit or even view their proxy settings.
Run Cypress.io with a test that needs to connect to a test application on localhost.

Result: the test URL (e.g. http://localhost:5000/__/#/tests/integration\sample_spec.js) will be passed to the local test server which cannot resolve it and returns 404.

Test code:

describe('POC', function () {
  it('should visit app under test', function () {
    cy.visit('http://localhost:5000')
  })
})

Additional Info (images, stack traces, etc)

Documentation of ProxyMode policy:

https://www.chromium.org/administrators/policy-list-3#Proxy

Entering chrome://net-internals/#proxy in the address bar of the browser window which was opened by Cypress shows that Cypress normally sets its own proxy, e.g.:
localhost:59175

When Cypress is blocked, you see your system proxy settings instead.

• Operating System: Windows
• Cypress Version: Beta 1.4.1
• Browser Version: Chrome 56

[dschulten]

On a related note - support for Firefox might help to work around this. #1096
As an alternative, setting up a development VM under Windows may give you a Chrome installation without blocked proxy settings.

[BasieP]

chrome doesn't start well with it's own policies. Cypress relies on chrome command line parameters to configure the proxy.
If chrome policy (system or chrome) are active, chrome doesn't respond to the --proxy options.
Not much cypress dev team can do about that i guess..

[dschulten]

The workaround to use Electron for TDD work is acceptable, as long as FF is not available. Use the Browser selector on the right hand side of the Cypress window to switch to it.
I close the issue because of available workarounds and low chance of getting a fix.

[brian-mann]

I'm not sure of OS level API's to read in system proxy settings - but at the very least you might have to duplicate the settings but as long as you provided the proxy configuration to Cypress it should work - just might not be automated.

[flotwig]

ProxyMode will always override the --proxy-server setting that Cypress needs to work.

As far as I can see, the only way to get around this would be to do some DLL Injection. We could theoretically write a DLL that replaces the functions that Chrome uses from winreg.h to read the Windows registry with functions that intercept the requests and return nothing for the ProxyMode policy. Then, we could use dllinjector or similar to launch Chrome with our custom DLL first, which would override the real functions defined in winreg.h.

As a temporary fix we could possibly put a warning when they launch Cypress or add a warning when launching any browser that isn't Electron if we detect this registry setting.

[flotwig]

I've been hacking at it using the Microsoft Detours package, which is the Microsoft-sanctioned DLL injection library. I was able to inject the sample DLLs they provide to trace winapi and registry function calls coming from chrome.exe using a command like this:

withdll.exe /d:trcreg64.dll ../Chromium/Application/chrome.exe

The problem I've now run in to is that chrome.exe spawns several copies of itself. The initial chrome.exe doesn't make any registry requests itself, that's farmed out to one of the other processes. So the last major piece of the puzzle here for blocking ProxyMode is figuring out how to automatically inject our support DLL into the forked chrome.exe copies. If we can do that, we can pretty easily repurpose Microsoft's tracereg registry example to write a DLL that does the kind of interception we need.

The rest is just a matter of bundling those binaries in with Cypress and changing the way the process is spawned in launcher to use withdll... if ProxyMode is detected.

Edit: Looked at some cli args for chrome. Could potentially use --browser-subprocess-path to send them to a pre-stubbed .exe. Or use --single-process so that no forking is done at all. Need to test.

Edit 2: I modified the Cypress Chrome extension to see if we can force the proxy that way, but Chrome ignores the extension's proxy settings if a ProxyMode configuration setting exists on the user's system:

On to another strategy...

Edit 3: There is a possible workaround (besides using Electron) if you have access to your Windows computer's registry:

If you have Local Administrator access to your computer, you may be able to delete the registry keys that are blocking installing extensions in Chrome:

1. Open Registry Editor (regedit.exe)
2. Visit HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome (or maybe HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update (Default installation of Cypress won't run tests under Chrome 72 #3667) or HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome)
3. Remove all items related to proxies, according to the Chromium Policy List (ProxyMode, ProxyServer, etc.)

(might want to back those up, just in case your normal Chrome requires them to be set to function properly)

[brian-mann]

@flotwig should we close this issue as wontfix since you provided the necessary workaround steps?

If not how should we conclude this issue?

[BasieP]

The workaround stoped working in the latest release...

…

On Mon, 1 Apr 2019, 05:37 Brian Mann, ***@***.***> wrote: @flotwig <https://github.com/flotwig> should we close this issue as wontfix since you provided the necessary workaround steps? If not how should we conclude this issue? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1253 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ab6pPS5c1IUkDSVvUV56gfUBkr0GpLwUks5vcX8RgaJpZM4R4MOr> .

[flotwig]

@BasieP Which workaround are you referring to? And what Cypress version are you using?