search

FelisCatus / SwitchyOmega

Manage and switch between multiple proxies quickly & easily.
GNU General Public License v3.0
21.29k stars 3.19k forks source link

dnsResolve() in Switch Profiles #703

Open jeka opened 8 years ago

jeka commented 8 years ago

Hello again,

Another feature request: Is is possible to implement isInNet() as condition type in auto-switch profile? Yes, I know that host regex can be used to implement the same conditions but writing proper regular expressions is not a trivial task.

Actually, I think this should come in 2 variants:

I am especially interested in the 2nd form as there is no way to express this intention currently and I have to manually switch profiles dozens of times on daily basis.

If this gets implemented It will make SwitchyOmega the complete solution for my (and not only my I guess) needs.

FelisCatus commented 8 years ago

Hi, please refer to #197 for the issues related myIpAddress().

The case is similar with dnsResolve. The function is available to PAC scripts but not to Chrome Extensions. Also, I don't think there is a way to do DNS requests in Chrome Extensions.

isInNet itself can be easily implemented using simple IP address comparisons. However, I don't think it would be useful if without dnsResolve and myIpAddress.

For these kind of functionalities, it is best to use PAC scripts. They can be reliably combined with other profiles through the PAC Profile in SwitchyOmega.

jeka commented 8 years ago

Hi, OK, I can get your point but: In my understanding (correct me if I am wrong) in case of auto-switch mode the extension just generates PAC file and gives it to chrome for use. Is that correct? If yes, then why you care about PAC functions available to extension at all? You are not using them directly anyway.

FelisCatus commented 8 years ago

@jeka SwitchyOmega also determines which proxy is in use and shows that through the extension icon color, etc. The exact matching rules are shown in the extension tool-tip for the user's inspection. So far this is carefully kept aligned with the actual PAC behavior so everything goes well.

It may confuse the user when the PAC is behaving correctly and selected a proxy, but the extension insists that direct connection is in use, with the grey icon there. Such inconsistency causes much trouble internally. The average user may have difficulty understanding this and consider the extension broken.

jeka commented 8 years ago

@FelisCatus OK, I understand your concerns. I will continue with my clicking fest then :) Actually even without this feature I find this extension extremely useful and the best in its class (I have found till now so far). Great work!

Just FYI found this solution for get-local-ip-of-a-device-in-chrome-extension. Its no so straightforward but gets job done.

FelisCatus commented 8 years ago

Thanks for pointing it out! I've updated #197 in comments based on the WebRTC leak. Let's merge the discussion with the myIpAddress thing into #197 so that we can focus on the dnsResolve case here.

FelisCatus commented 8 years ago

The dnsResolve check list:

  1. What are the use cases for this? How many users are going to use this if this is possible?
  2. Using dnsResolve freezes the thread of the PAC script and creates a notable delay for every single HTTP request. How laggy would this be?
  3. Is there any way to reliably predict the result of dnsResolve in Chrome Extensions?
    • Remember that dnsResolve only returns one of the IP addresses associated with a particular domain. This would be a big trouble when working with domains like google.com that has a lot of addresses in different subnets. There would be no way to tell which one it selects.
    • A public DNS service through HTTP is probably not going to work since it creates another HTTP request. Also that would change the result due to location-based DNS. For example, a service located in U.S. is likely to always give you U.S. IPs for google.com and the PAC is likely to get Japan IPs if you are in Japan.
jeka commented 8 years ago

The general use case I had in mind when I filled the issue is: isInNet( "IP", "NETWORK", "NETMASK") with IP = myIpAddress() as a special case

Example from my current rules in auto switch: Host RegEx ^10.87.[0-3].\d{1,3}$ -> DIRECT Not so readable at 1st glance, is it?

I would be nice if I can write: Host InNet 10.87.0.0 255.255.252.0 -> DIRECT

and for completeness for example (if possible at all) MyIP InNet 10.0.0.0 255.0.0.0 -> PROFILE

Much better and understandable (IMHO)

Now, I have no idea how would IsInNet() behave if you pass hostname to it instead of IP address. Thats why I included there dnsResolve() But maybe there is no need for this at all

Having said that I think my original title was more in line with my request :)

FelisCatus commented 8 years ago

@jeka Sorry for changing the original title, but I believe we are going to do myIpAddress + isInNet and dnsResolve + isInNet separately. Since myIpAddress + isInNet is already in discussion on #197, I think we might also have a dedicated issue for dnsResolve + isInNet. That's why I changed this.

isInNet(host, network, mask) behaves like isInNet(dnsResolve(host), network, mask), just for your reference. If you actually wanted something like Host RegEx ^10.87.[0-3].\d{1,3}$ (which only works for bare IP addresses but not domain names), please let me know.

Also, if your intended use case is InNet 10.87.0.0 255.255.252.0 -> DIRECT, then the bypass list (with proxy profiles) may work better for you. However, that configuration is specified with proxy profiles and not with switch profiles. Depending on your exact use case, it can be either a feature or a bug.

jeka commented 8 years ago

@FelisCatus No problem with changing title, I was just pointing out what was my original intention.

About your suggestion to use profiles, its not working for my use case ... At workplace I am forced to use proxy for internet access and proxy configuration is delivered by proxy.pac. This proxy.pac is not so simple and is auto-generated depending on client location and is changing quite frequently lately so I cant just download it and make my customization there as I was doing it in the past. That's why I am using switch profile with company wide proxy.pac as default proxy profile there. Also bypass list doesn't work for me either because I am using not only 'DIRECT' as target. Switch profiles work pretty well for me in general. They just have these shortcomings (IMO) I already pointed out, which are little annoying but I can live with.

And yes I had only bare IPs in mind for the form Host_InNet Net Mask -> PROFILE

Till now at least I haven't had an use case for isInNet(dnsResolve(host), network, mask) where host is a hostname and I cant write wildcard or regex to gain the effect I want. And I would say that I have fairly complex setup.

So in short (again):

FelisCatus commented 8 years ago

@jeka Created #705 for this. I didn't mean to re-title issues like crazy. I just want to keep everything organized, and unfortunately I didn't get it right this time. Sorry again for that.

Despite the issue management problems, host + isInNet is actually the easiest one to implement and I would start working on this when I'm free. Please subscribe to #705 for more updates.

jeka commented 8 years ago

@FelisCatus Great! Thanks

FelisCatus commented 7 years ago

v2.3.20 is released with IpConditon available. The condition type can be unlocked in Options > Switch Options > Show advanced condition types.