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/\"
         


        

Answer 1

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 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 Link 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.