[Improvement] Auto-detect proxy configuration

[gschier]

I have not done the research yet, but it looks like Electron has a function to resolve proxy settings based on the host OS configuration.

What

• Add checkbox to proxy settings to auto-detect proxy
  • This should be enabled by default
• Use Electron's session.resolveProxy to fetch proxy details for use with libcurl.

[LouisStAmour]

Seems appropriate to leave this comment here -- based on my reading of the source code, it looks like you can prefix the proxy URL with http://, https://, socks4://, socks4a://, socks5:// or socks5h:// to support different types of proxies. Socks proxies are often used when forwarding requests over an SSH bastion, for example. It's somewhat confusing that this is the case, but HTTPS proxy doesn't mean proxy over HTTPS, it means proxy for HTTPS traffic. It's the equivalent to using curl with the environment variable https_proxy (where for example, ftp_proxy will engage if ftp:// requests are made)

What I'd like to see, though it maybe relates to being able to select multiple environments, is the ability to change Curl network settings (currently in preferences) on a workspace or env level. Sometimes I need requests to ignore HTTPS, but most often I'd rather be warned if a cert is invalid because I'm sending (for example) sensitive GitHub credentials... Some calls will take forever, other calls I'd probably want to timeout right away. Some calls need a proxy, other calls, maybe not. :) I'm thinking this would make a good pull request attempt, but I'm not sure what would be the preferred approach to all this. Should we just allow template variables into network settings? That seems like a crude way to do it. Perhaps a better approach is to prompt the user on an per-environment basis which network settings they might want to override, and remove the settings from preferences? I could also see some folks wanting certain environments to have their own theme -- perhaps production changes the header to red, to highlight that you should be careful? This has quickly turned into another issue, "Moving settings into workspace or env preferences," and for that, I apologize. Just discovered Insomnia, and I'm still excited that it's open source and under active development. 👍

[LouisStAmour]

Hmm. Investigating the above issue led me to view the source code for resolveProxy which indicates that Electron returns Chrome's evaluation of any PAC (Proxy Auto-Configure) JS and returns the result of what to do with each request in PAC format. An example of how this PAC string response returned by ses.resolveProxy could then be parsed is at https://chromium.googlesource.com/chromium/src/net/+/master/proxy/proxy_server.cc ... I'm going to see if I can fork and add this functionality, as a PAC file might be one way to support proxies for certain URLs.

[gschier]

ability to change Curl network settings (currently in preferences) on a workspace or env level

I've actually been thinking of moving some of the global preferences to the Workspace level for a while now. I think it makes sense to have all the request-level preferences on the Workspace instead (Redirect Following, SSL validation, timeout, proxy), but this would still not provide the ability to do it on a per-request basis. I think the best solution would be the ability to define a setting at any level (workspace, env, folder, request) and have the most specific one win but that would add a lot of complexity to the app, and make it hard to understand what is going to happen. It'd be worth opening another issue for this if you'd like to discuss further.

[LouisStAmour]

The proxy settings can be per-request if a PAC file is written and kept up to date for the host, or if we add a file/url setting for the PAC script to use manually. The details on PAC (JavaScript-based proxy resolution) are at MDN. For example: https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_(PAC)_file#Load_balancingrouting_based_on_URL_patterns

But I agree, especially with PAC involved, it can be hard to predict what will happen to a request. PAC, after all, can make DNS lookups and/or change proxy use based on whether a subnet can be reached or not. Other than PAC, though, it might be possible to show the settings that would apply to each request within the UI, represented perhaps as a series of merges (as in Object.assign or immutable.js' merge) of state data from each level's preferences. (It might be pretty straightforward to write, as I think Object.assign ignores null objects automatically.)

[gschier]

I agree that it's probably possible to show the user where each setting came from, but I'd still be reluctant to add so much UI complexity for such a power-user feature.

I would rather make it possible to override settings using designated environment variable. This solution would have the following advantages:

• Wouldn't add UI complexity
• Could take advantage of cascading and recursive powers of environments
• Power users could still find it easily if we put a link in the settings menu to a help doc
• If the feature becomes popular, additional UI could be added on top of it if

I'm thinking an environment might look something like this.

{
  "my_variable": "foo",

  "INSOMNIA__TIMEOUT": 30000,
  "INSOMNIA_PROXY_CONFIGURATION": "auto"
}

And, when per-request variables (#203) eventually happen, these would also work at the request-level.

What are your thoughts on that?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.