Add an option to disable "*.localhost" bypass

[randomstuff]

The previous version of FoxyProxy would allow you to proxy *.localhost domain names which makes it possible to remap some *.localhost domain names to :

• another localhost port i.e. "http://myapp.localhost/ → http://127.0.0.1:9001".
• Unix-domain-socket services i.e. "http://myapp.localhost/ → /run/user/${pid}/app.sock".

Using *.localhost in this case is arguably semantically correct (as it is a local service) and currently makes it possible to host your HTTP service as a trusted context on Firefox.

However, this is not possible in the new version of the extension as it applies a global bypass for *.localhost which makes it impossible. While it is quite reasonable to have this protection by default, would it make sense to have an option to disable it ? (globally? per proxy?)

Caveats:

• would only work on Firefox (I think);
• might even not work on Firefox in the future.

[erosman]

The reason *.localhost was added to the Firefox localhost bypass was Implicit bypass rules. Allowing it would create an inconsistency between Firefox & Chrome.

Besides soxidizer, are there other general use-cases for *.localhost?

[randomstuff]

Besides soxidizer, are there other general use-cases for *.localhost?

Using an intercepting / application security proxy (BURP, ZAP, mitmproxy) for localhost, maybe?

[erosman]

another localhost port i.e. "http://myapp.localhost/ → http://127.0.0.1:9001/".

What about using another TLD e,g, http://myapp.local/ → http://127.0.0.1:9001/

[randomstuff]

What about using another TLD e,g, http://myapp.local/ → http://127.0.0.1:9001/

One benefit of *.local is that it is considered a secure context by Firefox. This means you can use all the features which are not enabled in non secure context. If you need these features, you might have to switch your application to HTTPS: you have to manage a certificate, private key, install an exception in the browser, etc.

[randomstuff]

Allowing it would create an inconsistency between Firefox & Chrome.

It is apparently possible to disable the default localhost-bypass on Chrome using a CLI option so allowing it as an advances option could possibly make sense even for Chrome.

[Atera]

Is there some workaround? I have local services that require proxying localhost, and I can't seem to find any way to use them now with FoxyProxy. Must I remove FoxyProxy and manually enter proxy details in Firefox when I use these applications or is there some way to achieve localhost proxying without removing FoxyProxy?

[erosman]

Proxying localhost has been disallowed by browsers.

[randomstuff]

Proxying localhost has been disallowed by browsers.

This must be new, this did not appear few days ago. I can't find this in the changelog however.

@Atera, this feature can apparently be disabled in Firefox with "network.proxy.allow_hijacking_localhost = true".

[randomstuff]

For now, even if "network.proxy.allow_hijacking_localhost=false", localhost hijacking is still possible with Firefox using an addon (through browser.proxy.onRequest.addListene).

[erosman]

This must be new, this did not appear few days ago. I can't find this in the changelog however.

It is 3 years old (Bug 1684241).

FoxyProxy 7 bypassed that restriction due to proxy.onRequest API. FoxyProxy 8 adheres to the restriction.

[n4chh]

Anyways having "network.proxy.allow_hijacking_localhost=true" is not enough for making it work on foxyproxy right?

[erosman]

Anyways having "network.proxy.allow_hijacking_localhost=true" is not enough for making it work on foxyproxy right?

The bypass is hardcoded in FoxyProxy for Firefox, to match Chrome behaviour. It would work for remote PAC though.

See also: Global Exclude

[Atera]

Anyways having "network.proxy.allow_hijacking_localhost=true" is not enough for making it work on foxyproxy right?

Just tested and no, it does not work with FoxyProxy.

[n4chh]

Anyways having "network.proxy.allow_hijacking_localhost=true" is not enough for making it work on foxyproxy right?

The bypass is hardcoded in FoxyProxy for Firefox, to match Chrome behaviour. It would work for remote PAC though.

See also: Global Exclude

Yeah I have read the global exclude post but I wasn't sure if it's any way for hijacking all localhost requests

[erosman]

Discussion

This topic has been labeled for discussion. If there are compelling reasons to change the behaviour, it will be looked into.

ATM, the policy of Chrome and Firefox is to never proxy localhost for security reasons.

Currently, Chrome has more restrictions than Firefox.

• Implicit bypass rules
• No Proxy for

FoxyProxy Implementation

https://github.com/foxyproxy/browser-extension/blob/feefecee8103c180b43a76ae3a80b9923c0e4138/src/content/on-request.js#L149-L178

[tmeidinger]

I can understand not to proxy 127.0.0.1 but the internet is classless since ages. But IMHO no proxying 192.168/16 is just plain wrong. Of course one wants to proxy private address space e.g. 10/8.

[Atera]

Well, by using the right advanced settings for Firefox, the browser can natively use a proxy for localhost (eg. using network.proxy.allow_hijacking_localhost). A number of applications and services could rely on communication on some port on the local machine (many applications run a webserver on localhost for configuration, etc.), and though this is something 'average users' may not need, proportionally I think advance users who know how to tweak settings are more likely to need localhost proxying. If FoxyProxy currently has no way to do something that Firefox allows via advanced settings, this is thus a needless restriction that would cause users like myself to have to uninstall FoxyProxy in order to use those features. Other browsers may have different approaches, but for Firefox, generally the approach many have taken is to allow advanced settings to enable unusual or dangerous behaviour, but never to outright prevent users from doing something intentionally if that's what they really want. I understand you're trying to unify behaviour between Firefox and other browsers like Chrome, but don't go against this ethos please. Either create a simple toggle to switch on or off this behaviour, or else disable the behaviour on Firefox to allow users to continue using FoxyProxy as they had been. The only unacceptable option I think is to outright prevent users from using their browser as they wish if they are willing to tweak settings in order to enable existing/previous behaviour.

[erosman]

All feedbacks are welcomed and will be considered for the next update.

[Atera]

All feedbacks are welcomed and will be considered for the next update.

Given the severity of this, however, I think it would be best to very quickly either push a new update/fix, or even pull the existing update as it seems to be causing numerous issues for many people. Between losing settings and stopping existing workflows, an urgent update may be warranted.

[tmeidinger]

Proxying localhost has been disallowed by browsers. As you can see 192.168.0.0/16 is not mentioned at all.

Every couple of minutes there are additional 1-star reviews regarding FoxyProxy. And probably hundreds of silent but disgruntled users.

[erosman]

v8.3 is already uploaded and awaiting review. Any changes regarding this issue would be for v8.4

[0xquad]

Adding my +1 to this as also mentioned in my other general ticket. This is critical to some users on a functionality level. Breaking this breaks the workflow of many users for legitimate and serious use cases (i.e. for work). I hope it really gets reverted soon with other fixes. For me, 8.x is plain unusable unfortunately. 🙁

[randomstuff]

Even on Chrome, it is still possible to override the localhost bypass with an extension:

var config = {
    mode: "fixed_servers",
    rules: {
        singleProxy: {
            scheme: "socks5",
            host: "127.0.0.1",
            port: 8080
        },
        bypassList: [
            "<-loopback>"
        ]
    }
};

chrome.proxy.settings.set(
    {value: config, scope: 'regular'},
    function() {}
);

[Cheekysoft]

Like many others, this is a blocker for me that stops me using v8+

I have web admin interfaces that run in my organisation's Azure estate. The only access is via an SSH jump host (i.e. local socks5 proxy) and the remote systems that run the web admin interfaces do not have a public IP addresses. I have a local DNS entry for adminx that maps the name adminx to 127.0.0.1. When funneled through the socks5 proxy, this allows access to https://adminx:port/xxx to use the web tools there.

However, https://adminx:1234/xxx appears to not be proxied by foxyproxy 8+, even if I set foxyproxy 8+ to single-proxy mode.

This means I can't do my job with a foxyproxy8-enabled browser profile, and i've had to downgrade back to to foxyproxy 7.

[erosman]

I am discussing the issue with the founder of FoxyProxy and some or all of localhost checks will be removed in v8.4

[Atera]

I am discussing the issue with the founder of FoxyProxy and some or all of localhost checks will be removed in v8.4

Having the checks is fine, as long as there's a switch to turn them on/off. But I think more importantly, the v8.4 update needs to come as soon as possible, even if only with a temporary solution while a more developed release is prepared.

[randomstuff]

In the meanwhile, if you really need the feature urgently, you can copy this project https://github.com/randomstuff/some-proxy-web-extension patch it as you wish and install it as a temporary extension through about:debugging (Firefox only). :heart:

[erosman]

We can update FoxyProxy Basic (same code) soon but FoxyProxy (standard) will take time to become available due to the AMO review process.

[erosman]

It is done in v8.4 We are uploading v8.4 to AMO. FoxyProxy Basic (same code) will be available shortly but FoxyProxy (standard) will take time due to the AMO review process.

[randomstuff]

I confirm this is working :bow: :+1: . (By the way, I did not find an explanation about the difference between Classic and Basic. As far as I understand, the only difference is the AMO review, is that right?)

[ericjung]

Thank you for confirming.

I did not find an explanation about the difference between Classic and Basic

As of 8.x, there are no differences anymore. We will add this to the README. Previously, the difference was that Standard supported “url patterns” and Basic did not. Now they are identical. The listings cannot be merged due to limitations of the Chrome and Mozilla stores.

[erosman]

The unified code of FoxyProxy v8 allows settings to be shared between FoxyProxy Standard & Basic, Chrome & Firefox.