Bypass blocking of subresource requests whose URLs contain embedded credentials

Question

I have been automatically authenticating users visiting our internal wiki via a link with a token in the URL like this:

href="https://user:pass@host/"

In Chrome 59, this is being prevented.

[Deprecation] Subresource requests whose URLs contain embedded credentials (e.g. https://user:pass@host/) are blocked.

I read and I bypassed it in an ajax request like this:

how to replace embedded credentials in subresource requests

========================================================================

My Question is:

Does anyone know how to do it directly in the link, or can you provide some kind of workaround? Is this even possible?

Answer 1

Passing the command line option '--disable-blink-features=BlockCredentialedSubresources' restores the expected behavior. If you're using Selneium, you can pass it as an args option in the Browser Capabilities to restore the expected behavior.

PHP: 'chromeOptions' => array('args' => ['--disable-blink-features=BlockCredentialedSubresources']);

Python: capabilities['chromeOptions'] = {'args': ['--headless']}

According to the Chromium ticket (https://bugs.chromium.org/p/chromium/issues/detail?id=731618) this behavior may not be restored in future versions despite it being in 'Deprecation'. In this case, it might be best to look at ssh conduits for testing or whitelist the IP if possible to prevent the HTTP Auth interaction.

Anthony

Answer 2

If your page includes css, javascript or other stuff with relative ("folder/file") or base-relative ("/folder/file") locations, then the problem is that these included files would be fetched from a URL relative to the base URL of the page, which includes a user:pass component.

It is that user:pass componenent (which you possibly never meant to imply anyway...) which makes the URL of the subresources illegal, following this change to Chrome.

If that is your problem, you can fix it by adding a <base href="https://host/"> tag to your page (i.e. the same base address, but without the user:pass component). (If your page is in a subdirectory, you need to include the subdirectory in the base href as well, for fully relative URLs to work.)

To be clear, links like <a href="https://user:pass@host/">Link</a> still work (as long as the user:pass URL is in a link which opens in a new page, and is not a URL for an iframe, say - that is now banned). But even when the link works, the problem I've described above applies to elements included with relative paths in the newly opened page.

UPDATE:

This has been accepted as a bug in Chrome, directly related to the new changes banning user:pass in subresource URLs. Unfortunately, following through the links in that discussion, it seems that one proposed and quite likely solution is to remove support for user:pass URLs entirely. Any informed comments added to that discussion and arguing in favour of keeping this feature would presumably help.

Answer 3

To handle this, we have to pass chrome options : "--disable-blink-features=BlockCredentialedSubresources");

Complete code is mentioned below :

ChromeOptions options = new ChromeOptions();
        options.addArguments("--start-maximized");
        options.addArguments("--disable-blink-features=BlockCredentialedSubresources");

        Map<String, Object> prefs = new HashMap<String, Object>();
        prefs.put("credentials_enable_service", false);
        prefs.put("profile.password_manager_enabled", false);
        options.setExperimentalOption("prefs", prefs);

        DesiredCapabilities capabilities = DesiredCapabilities.chrome();
        capabilities.setCapability(ChromeOptions.CAPABILITY, options);
        driver = new ChromeDriver(capabilities);