I had reason to be concerned/examine about Node-Red behind a corporate proxy.
2 days later, and I have some observations:
1/ the http request node only does HTTP proxying. Hence all (?) the information is available on the local LAN (even for HTTPS).
2/ the MQTT node uses https-proxy-agent for WS and WSS. (but does not support no_proxy).
3/ the Websocket node does not support proxy.
Since we have https-proxy-agent now available, should we modify httprequest to use it, and add it to websockets? This would mean that ALL proxied requests would be place via HTTP CONNECT rather than in plain text over an HTTP proxy.... or should there be options?
For the moment, it's unlikely that I can work on the current Node-Red version.
For anyone who needs to be behind a corporate proxy with authentication, but who does not want to store credentials, then I've found https://github.com/genotrance/px and forked and 'fixed' (?!!) at https://github.com/btsimonh/px/tree/delconnected
This is a local proxy which node-red can use (on windows), which then forwards on to the corporate proxy using the current windows user. It was very difficult to find support for this, and it seems there is no node package which does this at the moment.... (it's python ).
Nice breakdown Simon, thanks. This is important for some use-cases certainly.
One thing, there are a number of local proxy services for Windows that should enable you to get round (some of?) these issues I think. Sorry, been a while since I used any so I can't remember them off the top of my head but I know that I used to occasionally use one when the work proxy was Microsoft based since that required NTLM authentication which was rarely supported by open source tools (or indeed any tools at all!).
small update on this.
I've added one more commit to it, because HttpsProxyAgent contains a 'defaultPort', which gets used in node's own request code. This lead to when asking for http://www.google.com, you actually end up asking the proxy (via CONNECT) for a connection to www.google.com:443 instead of :80.
So the commit adds a correct defaultPort to the request options.
Also note that stupidly if you set process.env.http_proxy = null; - then what you get is process.env.http_proxy == 'null', so I took out comparisons with null in favour of using simple falsy, so as not to encourage people to set to null!.
s
I have just submitted a PR relating to this, based on 1.0.1.
It brings mqtt and websocket up to the same level as httprequest, except for ability to select a proxy config node.
The final push (httprequest) adds the above port number fix - but this is not specifically present in mqtt of websocket - i'm not sure if it is required.
).