kaivean
iOS: Support "Automatic" proxy configuration
iOS has the option to define an "automatic" proxy configuration, which is really just a URL to a JavaScript function, which returns which proxy to use for a given host.
When setting such a a configuration on my iPad, await SystemProxy.getProxySettings() only returns null though.
Is that a known issue / would this need some other native API to access this?
More information is available at: https://www.giantstride.gr/el/proxy-autodiscovery/
When I inspect the unfiltered dictionary returned from dynamic proxySettingRes = await _channel.invokeMethod('getProxySettings'); I can see the following:
{ProxyAutoConfigEnable: 1, ExceptionsList: [*.local, 169.254/16], FTPPassive: 1, ProxyAutoConfigURLString: http://example.com/wpad.dat, __SCOPED__: {en0: {ProxyAutoConfigEnable: 1, ExceptionsList: [*.local, 169.254/16], FTPPassive: 1, ProxyAutoConfigURLString: http://example.com/wpad.dat}}}
So the key ProxyAutoConfigURLString would be useful to return.
Not sure how practical is would be to then fetch that file and interpret it with e.g. https://pub.dev/packages/flutter_js, but it looks like createHttpClient.findProxy specifically has the capability to use a different proxy per URL.
I've had some success with https://gitlab.com/yamsergey/platform_proxy which is described here: https://yamsergey.medium.com/flutter-and-proxy-1e2b6acd24f5
I was able to retrieve a domain and port from automatic settings (that use a pac) on both an iphone and android device.
Perhaps you could reach out to sergey or the same logic could be applied in system_proxy?
Perhaps you could reach out to sergey or the same logic could be applied in system_proxy?
Well, if that package works for you, that's great. Couldn't you just use that package then, instead of waiting for this to be extended? Or is this giving you anything the other is not?
Checked the Android implementation of it, and that seems like a different method call is needed, but that should be easy to add if the need comes up.
Thanks for the pointer :)
Apologies if the tone sounded demanding, I am using that code already - I simply wanted to pass on the information since it seemed like something you were working on.
You're welcome!
Apologies if the tone sounded demanding, I am using that code already - I simply wanted to pass on the information since it seemed like something you were working on.
Great. No worries, I was just curious if it would be worth to fix/extend this package or whether the recommendation would be just to use the other one.
Since that works fine for you and already contains the desired behavior, I suppose we'll also just look into switching if the need comes up to support this beyond iOS.
Can be closed as implemented by #9
While it's nice to get the URL out now, I think this is only partially solving the problem for consumers of this package – because what should they do with that URL?
The approach we took back then to parse out the "only" proxy to be found in the JavaScript file worked for us, but does not seem like a general solution.
In the end one would need a function like (Request URL) -> Proxy Settings as they could change (with each request, for every domain, etc.). But fully supporting that would entail running the JavaScript locally, and then also injecting that into one's request pipeline (e.g. some wrapper or Dio middleware).
But since no-one else asked for or +1-ed this, there might just not be any need for this anymore. Maybe by now the "native HTTP" (like https://pub.dev/packages/cupertino_http) is good enough for this use-case? (As that should handle the proxy settings like the underlying device does.) That would probably also be my preferred solution to try if I had the need again, so we don't have to re-implement system behavior in the app.