Giter VIP home page Giter VIP logo

proxy-vole's Introduction

proxy-vole

Proxy Vole is a Java library to auto detect the platform network proxy settings.
Note: This library is a fork of the now dead proxy-vole project by Bernd Rosstauscher hosted at Google Code.

Introduction

The library provides some proxy setting search strategies to read the proxy settings from the system config (Windows, KDE, Gnome, OSX), browser config (Firefox, IE) or environment variables and provides you an ready to use proxy selector.

Why a fork?

  • Can't contact Bernd Rosstauscher.
  • Google Code is dead by now.
  • proxy-vole seems to be dead even longer. Last commit mid 2015. Last release end 2013.
  • proxy-vole is not available on any public Maven repository. Needed to change the Maven coordinates and Java package names to be able to push it to Maven Central on my own.
  • I don't like the Windows DLL and usage of JNI. Replaced both by JNA.

Usage

Using the default strategy to find the settings

// Use the static factory method getDefaultProxySearch to create a proxy search instance 
// configured with the default proxy search strategies for the current environment.
ProxySearch proxySearch = ProxySearch.getDefaultProxySearch();

// Invoke the proxy search. This will create a ProxySelector with the detected proxy settings.
ProxySelector proxySelector = proxySearch.getProxySelector();

// Install this ProxySelector as default ProxySelector for all connections.
ProxySelector.setDefault(proxySelector);

Modifying the search strategy

// Create a not configured proxy search instance and configure customized proxy search strategies.
ProxySearch proxySearch = new ProxySearch();
if (PlatformUtil.getCurrentPlattform() == Platform.WIN) {
    proxySearch.addStrategy(Strategy.IE);
    proxySearch.addStrategy(Strategy.FIREFOX);
    proxySearch.addStrategy(Strategy.JAVA);
} else if (PlatformUtil.getCurrentPlattform() == Platform.LINUX) {
    proxySearch.addStrategy(Strategy.GNOME);
    proxySearch.addStrategy(Strategy.KDE);
    proxySearch.addStrategy(Strategy.FIREFOX);
} else {
    proxySearch.addStrategy(Strategy.OS_DEFAULT);
}

Improving PAC performance

When your system uses a proxy automation script (PAC) Javascript is used to determine the actual proxy. If your program needs to access a lot of HTTP URLs, then this might become a performance bottleneck. To speed things up a little bit, you can activate a cache that will store already processed URLs. When a cached URL is accessed the Javascript execution will be skipped and the cached proxy is used.

// Use the static factory method getDefaultProxySearch to create a proxy search instance 
// configured with the default proxy search strategies for the current environment.
ProxySearch proxySearch = ProxySearch.getDefaultProxySearch();

// Cache 20 hosts for up to 10 minutes. This is the default.
proxySearch.setPacCacheSettings(20, 1000*60*10, CacheScope.CACHE_SCOPE_HOST);

How to handle proxy authentication

Some proxy servers request a login from the user before they will allow any connections. Proxy Vole has no support to handle this automatically. This needs to be done manually, because there is no way to read the login and password. These settings are stored encrypted. You need to install an authenticator in your Java program manually and e.g. ask the user in a dialog to enter the username and password.

Authenticator.setDefault(new Authenticator() {
    protected PasswordAuthentication getPasswordAuthentication() {
        if (getRequestorType() == RequestorType.PROXY) {
            return new PasswordAuthentication("proxy-user", "proxy-password".toCharArray());
        } else { 
            return super.getPasswordAuthentication();
        }
    }               
});

Choose the right proxy

Please be aware a Java ProxySelector returns a list of valid proxies for a given URL and sometimes simply choosing the first one is not good enough. Very often a check of the supported protocol is neccessary.

The following code chooses the first HTTP/S proxy.

Proxy proxy = Proxy.NO_PROXY;

// Get list of proxies from default ProxySelector available for given URL
List<Proxy> proxies = null;
if (ProxySelector.getDefault() != null) {
    proxies = ProxySelector.getDefault().select(uri);
}

// Find first proxy for HTTP/S. Any DIRECT proxy in the list returned is only second choice
if (proxies != null) {
    loop: for (Proxy p : proxies) {
        switch (p.type()) {
        case HTTP:
            proxy = p;
            break loop;
        case DIRECT:
            proxy = p;
            break;
        }
    }
}

Logging

As of 1.0.5 Proxy Vole does use the SLF4J API as the default logging backend. See the Logger.Slf4jLogBackEnd class. If you want to use another logging API or a custom logger you can install your own logger.

// Register MyLogger instance 
Logger.setBackend(new MyLogger());

Testing PAC

Testing the PAC parser can be problematic, because the myIPAddress() method returns different results on different machines. Therefore the system property com.github.markusbernhardt.proxy.pac.overrideLocalIP can be set for unit tests. It's value will always be used as myIPAddress in all PAC scripts.

System.setProperty(PacScriptMethods.OVERRIDE_LOCAL_IP, "123.123.123.123");

Proxy Vole Tester

There is also a small GUI to test the different search strategies. Simply start the jar-with-dependencies or directly the class com.github.markusbernhardt.proxy.ui.ProxyTester.

Screenshot

Motivation

Today more and more applications try to take direct advantage of Internet connectivity and web services to bring web content to your desktop. Java has very good network and Internet connectivity with build in APIs for HTTP, HTTPS, FTP and a web services stack. But the first thing that you need, to use all this fantastic technology, is a working Internet connection. And this is where Java lacks a lot in my opinion. When you develop an applet or an Java Webstart application the situation is quite good. The Java Plugin will use the proxy settings and connections as used by the browser, but for standalone applications the situation is quite unsatisfactory. You have to ask your users to twiddle with system properties and every Java application has it's own way of setting proxy configurations. In business environments where you often can find proxy configuration scripts you are stuck.

Current Situation

To set the proxy settings in Java you can use some (documented, but hard to find) system properties on application startup. At runtime you can use the ProxySelector API to configure the proxy settings. Java even comes with a system property to detect the system proxy settings automatically, but this one is poorly documented and unreliable in its behaviour.

The Solution

Use the Proxy Vole library to provide network connectivity out of the box for your Java application. It provides strategies for auto detecting the current proxy settings. There are many configurable strategies to choose from. At the moment Proxy Vole supports the following proxy detection strategies.

  • Read platform settings (Supports: Windows, KDE, Gnome, OSX)
  • Read browser setting (Supports: Firefox 3.x+, Internet Explorer; Chrome and Webkit use the platform settings)
  • Read environment variables (often used variables on Linux / Unix server systems)
  • Auto detection script by using WPAD/PAC (Not all variations supported)

proxy-vole's People

Contributors

develar avatar jasonjmcghee avatar jpasski avatar jstammi avatar markusbernhardt avatar nerdydrew avatar onixgh avatar phansson avatar pozo avatar rossi1337 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

proxy-vole's Issues

SocketException "Unknown proxy type : HTTP" on specific connections

Software environment is:

  • proxy-vole version is 1.0.2
  • both Windows 10 64-bit and Windows 7 64-bit
  • both Java 1.7.0.71 and Java 1.8.0.102.

I'm getting constant java.net.SocketExceptions "Unknown proxy type : HTTP" here, on specific complex proxy chains in minimum two of my customer's networks. They're operating big networks with thousands of users and cascading (chained) proxies, it seems.

I don't have problems in smaller environments with only one proxy or direct connections, and that's one of the curiosities: I'm having problems using the automatic routines on this complex environment only, using a FixedProxySelector is never a problem.

Please find test code and different outputs attached for

  1. (not working) ProxySearch.getDefaultProxySearch().getProxySelector()
  2. (not working) new PacProxySelector(new UrlPacScriptSource("..."))
  3. (working) new FixedProxySelector("...", 8080)

I wont have access to this complex network for long, so please assist soon. I will support as good as possible, vice versa.

Guido

jna: Can't find dependent libraries using WinHttpCurrentUserIEProxyConfig

Our auto-build fails for a test using proxy-vole for proxy detection since using java 9.0.1 on a up-to-date windows 7 build slave:

java.lang.UnsatisfiedLinkError: ...\jna--1712433994\jna5672512838192935606.dll: Can't find dependent libraries

java.lang.NoClassDefFoundError: Could not initialize class com.github.markusbernhardt.proxy.jna.win.WinHttpCurrentUserIEProxyConfig

This is caused by using jna 4.2.2 being dynamically linked against msvcrt100.dll. This was reported and fixed for jna. It should be fixed for 4.3.0 I assume (most recent is 4.5.1; see java-native-access/jna#636).

This does not become obvious with using java 1.8 as the dll is part of the 1.8 jre's.

Please upgrade your dependency to jna to a newer persion ... ?

Logger is not thread safe

The com.github.markusbernhardt.proxy.util.Logger class is not thread safe. Consider making backend volatile (and updating how it's accessed accordingly) or use some other thread safe mechanism.

Problems with new Proxy-Vole 1.0.4

I have problems with new Proxy-Vole 1.0.4 on different client computers. A rollback to 1.0.3 actually has helped in first situation, so it must have to do with the new proxy autodetection code. Problem is, I don't have direct access to these machines in different company networks of my customers.

1. NoClassDefFoundError

Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class org.mozilla.javascript.VMBridge
        at org.mozilla.javascript.Context.exit(Context.java:434)
        at delight.rhinosandox.internal.RhinoSandboxImpl.assertContextFactory(RhinoSandboxImpl.java:68)
        at delight.rhinosandox.internal.RhinoSandboxImpl.evalWithGlobalScope(RhinoSandboxImpl.java:91)
        at com.github.markusbernhardt.proxy.selector.pac.JavaxPacScriptParser.setupEngine(JavaxPacScriptParser.java:80)
        at com.github.markusbernhardt.proxy.selector.pac.JavaxPacScriptParser.<init>(JavaxPacScriptParser.java:40)
        at com.github.markusbernhardt.proxy.selector.pac.PacProxySelector.selectEngine(PacProxySelector.java:76)
        at com.github.markusbernhardt.proxy.selector.pac.PacProxySelector.<init>(PacProxySelector.java:41)
        at com.github.markusbernhardt.proxy.util.ProxyUtil.buildPacSelectorForUrl(ProxyUtil.java:90)
        at com.github.markusbernhardt.proxy.search.browser.ie.IEProxySearchStrategy.createPacSelector(IEProxySearchStrategy.java:114)
        at com.github.markusbernhardt.proxy.search.browser.ie.IEProxySearchStrategy.getProxySelector(IEProxySearchStrategy.java:40)
        at com.github.markusbernhardt.proxy.ProxySearch.getProxySelector(ProxySearch.java:216)
        at de.credo.afplookup.license.RegistrationProperties.activateProperties(RegistrationProperties.java:122)
        at de.credo.afplookup.license.Registration.<clinit>(Registration.java:80)

2. UnsatisfiedLinkError

Exception in thread "main" java.lang.UnsatisfiedLinkError: [...]\jna-1224345557\jna7768348195287699756.dll: Can't find dependent libraries
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(Unknown Source)
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.load0(Unknown Source)
        at java.lang.System.load(Unknown Source)
        at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:851)
        at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:826)
        at com.sun.jna.Native.<clinit>(Native.java:140)
        at com.sun.jna.Pointer.<clinit>(Pointer.java:41)
        at com.sun.jna.Structure.<clinit>(Structure.java:2078)
        at com.github.markusbernhardt.proxy.search.browser.ie.IEProxySearchStrategy.readIEProxyConfig(IEProxySearchStrategy.java:67)
        at com.github.markusbernhardt.proxy.search.browser.ie.IEProxySearchStrategy.getProxySelector(IEProxySearchStrategy.java:38)
        at com.github.markusbernhardt.proxy.ProxySearch.getProxySelector(ProxySearch.java:216)
        at de.credo.afplookup.license.RegistrationProperties.activateProperties(RegistrationProperties.java:122)
        at de.credo.afplookup.license.Registration.<clinit>(Registration.java:80)

I have had a look into the code in second case, and it seems code was not able to load WinHttp.dll. I don't know why, if this file doesn't exist on client computer or there's another problem in finding it (any app on this machine is deployed as App-v package, so software within this package may not have access to Windows system libraries by default).
Both cases are not related neccessarily. I'm putting them together in one issue anyway, because of the fact that these problems never raised the months before upgrading to Proxy-Vole 1.0.4.

Any idea? Both environments are complex company networks with internet access restricted very creatively, while both users where able to surf at the same time. As an example: After rollback to version 1.0.3 in first case license server access for my software wasn't able anyway. It turned out that user had also to fake user agent string of my software to look like a browser. That's a functionality I had to implement months ago already for another customer, so faking user agent strings is not part of this proxy-vole 1.0.4 issue.

Regards
Guido

Proxy-Vole does not find proxy

I was working with de.rosstauscher.proxy_vole (4.0.0) which worked fine.
Decided to shift to this fork as it is more recent, but it does not detect the proxy using ANY strategy. (The original proxy_vole was able to detect the proxy using 5 strategies.)

Is this still a functioning project?

The original proxy-vole, merge and/or unfork?

It appears that the original proxy-vole library has no binary releases since 2013, and the last commit was in 2015. https://code.google.com/archive/p/proxy-vole/source/default/commits

I have some questions/requests:

Are you monitoring changes in the original proxy-vole and pulling those changes in here?
What do you think of merging your changes back into the original project?
What do you think of completely unforking, and merging both projects back together?

Detecting IE proxy settings hangs for 4 minutes

I am running into an issue where a java app will literally hang for 4 minutes on the line in bold below. it will ultimate come back and not detect a proxy setting, but I would like for it fail fast. Any thoughts on what might be causing this.

public IEProxyConfig readIEProxyConfig() {

	// Retrieve the IE proxy configuration.
	long start = System.currentTimeMillis();
	**WinHttpCurrentUserIEProxyConfig winHttpCurrentUserIeProxyConfig = new WinHttpCurrentUserIEProxyConfig();**
	long stop = System.currentTimeMillis();
	
	long difference = stop - start;
	System.out.println(difference);

Replace the Logger interface with an SLF4J reference, please

com.github.markusbernhardt.proxy.util.Logger is serving exactly the same purpose as SLF4J: a facade for the real logging backend. (LogBack and Log4J are logging backends, not logging facades like SLF4J and Logger.)
Footprint is not really a consideration: SLF4J itself is just 32k jar size; proxy-vole alone comes at 140k.
For projects that already use SLF4J, the size burden is really the other way round: they need an extra adapter class, in this case from Logger to SLF4J. It's actually a deterrent: A library that requires extra coding just to use it means an additional entry barrier.

Proxy autodetect not working

Hello,

I am facing issue when only auto detect is selected.
Proxy-vole is able to detect that autodetect flag is on, but library is not able to read the URL.

boolean result = WinHttp.INSTANCE.WinHttpDetectAutoProxyConfigUrl(dwAutoDetectFlags, ppwszAutoConfigUrl);

This is a code in your library and it returns false with last error - 87.

Please support, as we want seamless proxy behavior as that of windows. Every thing else is working fine.

Regards,
Nameeta

Feature Request: useful toString

Hard to know all possibly proxy setups ahead of time, so supporting a simple toString including relevant details like the PAC target would be helpful

Currently

com.github.markusbernhardt.proxy.selector.whitelist.ProxyBypassListSelector@79e4c792

Take advantage of Windows' own WPAD

Windows has a function, WinHttpDetectAutoProxyConfigUrl, which finds the URL for the PAC file, if it exists. This function supports both DHCP and DNS discovery method. In other words: this function does the WPAD for you.

Currently, Proxy-vole doesn't make use of this function on Windows. Instead it tries to do the WPAD on its own.

I see a number of advantages to use this Win32 function on the Windows platform:

  • We'll get WPAD-DHCP discovery "for free" (something that proxy-vole currently doesn't do)
  • There's likely to be a significant performance benefit. This is because Windows has a background process, WinHTTP Web Proxy Auto-Discovery Service, which does the WPAD in the background. In other words, most likely the WinHttpDetectAutoProxyConfigUrl function will return instantly because it only has to ask the background process.
  • It generally seems a good idea to 'outsource' WPAD to the underlying OS (if supported, of course). There are certain security concerns related to WPAD and by outsourcing then proxy-vole will not have to worry about that part. If there's a security flaw in the WPAD then it will be a problem for Microsoft, not proxy-vole.

The function has existed since Windows XP and exists on Windows Server platform too. So no problem there.

The downside is that proxy-vole's WPAD will then be different on Windows platform vs the other OS'es.

I'm interested in your thoughts on this. If it seems like a good idea then I'll like to work on a pull request.

Proxy autodetect / is not working

Hello,

Something is not right with the forked edition of proxy-vole when it comes to Proxy auto detection.

On my PC IE proxy setting is set to Autodetect.

As you can see from the screen shot the original proxy-vole (right) detects the proxy script and correctly find a proxy host and port.
This is not a case for a forked edition (left).

image

Thanks

Mindaugas

Proxy for 127.0.0.1

Hi.
Wouldn't be better to return allways DIRECT for xxx://127.0.0.1 without even checking proxy settings.

Regards

IE fixed socks proxy parsed as http

How to repro:

  1. Go to IE settings pane, set up a socks proxy
  2. Look at the ProtocolDispatchSelector you get from ProxySearch proxySearch = ProxySearch.getDefaultProxySearch().getProxySelector();

Expected: The proxy inside the ProtocolDispatchSelector has type SOCKS, network connectivity works
Reality: The proxy inside the ProtocolDispatchSelector has type HTTP, network connectivity doesn't work

I hotfixed this w/ the patch below, but it doesn't seem right - for some reason the proxy doesn't work if it's not set as the fallback selector.

--- a/src/main/java/com/github/markusbernhardt/proxy/search/browser/ie/IEProxySearchStrategy.java
+++ b/src/main/java/com/github/markusbernhardt/proxy/search/browser/ie/IEProxySearchStrategy.java
@@ -143,9 +144,14 @@ public class IEProxySearchStrategy implements ProxySearchStrategy {
addSelectorForProtocol(p, "https", ps);
addSelectorForProtocol(p, "ftp", ps);
addSelectorForProtocol(p, "gopher", ps);

  •           addSelectorForProtocol(p, "socks", ps);
              addFallbackSelector(p, ps);
    
  •           if(p.containsKey("socks"))
    
  •           {
    
  •                   String socks = p.getProperty("socks");
    
  •                   String[] fo=socks.split(":");
    
  •                   ps.fallbackSelector=new FixedSocksSelector(fo[0], Integer.parseInt(fo[1]));
    
  •           }
              ProxySelector result = setByPassListOnSelector(bypassList, ps);
              return result;
      }
    

Can it work on OpenJDK.

Hello. I try to run a sample code of ProxyVole with the OpenJDK.
And I get this exeption:
Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/jna/Structure
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at com.github.markusbernhardt.proxy.search.browser.ie.IEProxySearchStrategy.readIEProxyConfig(IEProxySearchStrategy.java:67)
at com.github.markusbernhardt.proxy.search.browser.ie.IEProxySearchStrategy.getProxySelector(IEProxySearchStrategy.java:38)
at com.github.markusbernhardt.proxy.ProxySearch.getProxySelector(ProxySearch.java:216)
at toto.Toto.main(Toto.java:22)
Caused by: java.lang.ClassNotFoundException: com.sun.jna.Structure
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 16 more

Is it possible to run ProxyVole on OpenJDK? How can it be done?

Native ProxySelector for Windows platform

More options exist these days in Windows API than when proxy-vole was first conceived.

I'm wondering whether the time has come to have an additional ProxySelector which outsource everything to Windows. Currently proxy config auto detection is outsourced on Windows, but proxy resolution is not, but it could be, because WinHTTP API now has functions for this. So, you can imagine a ProxySelector in proxy-vole which does just that. Such a ProxySelector would constantly call Windows to figure out which proxy to call for a given http/https request.

I would name it something like WindowsNativeProxySelector. Unlike the other ProxySelectors in the proxy-vole lib this new ProxySelector wouldn't actually need to know anything about settings, nor would it need to download PAC or even to evaluate it for each URL. In the crucial select() method it would simply ask Windows for the answer. It would essentially be a black box.

The (small) downside of such a ProxySelector is that it would need to cross the java<-->native barrier for every call to the ProxySelector. Since we're basing ourselves on JNA (not JNI) then this may not be as quick as we would like. Dunno. Perhaps a non-issue?

The upside is that it would get rid of the nightmare of figuring out what the current settings in registry are, how to locate PAC file, how to download it (including if downloading requires silent auth) and how to evaluate it in a Javascript parser. Use of this ProxySelector would pretty much guarantee the same user experience as those applications developed by Microsoft, e.g. later version of Microsoft IE and Microsoft Edge in particular.

I'm logging my thoughts here to collect input on the idea ... before I move to hacking it up and creating a pull request.

Unresponsive proxy with ProxyListFallbackSelector -> NPE

How to reproduce:

  1. Set up a SOCKS proxy set in IE proxy.pac. This doesn't happen if SOCKS proxy is supplied with -DsocksProxyHost parameter on JVM command line, as that results in an ProtocolDispatchSelector instead of ProxyListFallbackSelector
  2. Take down network connectivity to that proxy (e.g. don't start ssh -D )
  3. Make two http requests

Expected result: Network fails with IOException, which applications expect and usually know how to deal with

Actual result: ProxyListFallbackSelector clears the proxy list on first http request, second request gets an NPE somewhere deep in sun.net.www...

Java 11: "Warning: Nashorn engine is planned to be removed from a future JDK release"

Using proxy-vole 1.0.5 and Java 11. When a PAC script is used to set proxy settings, proxy-vole logs this message to the console:

Warning: Nashorn engine is planned to be removed from a future JDK release

This does not occur in earlier Java versions. My Googling has revealed that "this is related to the ScriptManager class in the Buscript libary. This warning started to appear from Java 11. It seems Nashorn engine is no longer maintaned and they are deprecating it from Java 12."

It looks to me like this might mean that proxy-vole will not be able to use PAC scripts when running in Java 12 or later (haven't personally tested in Java 12).

Strings are not interpolated in logs

Placeholders are shown instead of interpolated values. Note the curlies where the actual values should be:

Logger$Slf4jLogBackEnd [sdbe-compute-7] Detecting platform. Name is: {0}
Logger$Slf4jLogBackEnd [sdbe-compute-7] Detected Mac OS platform: {0}
Logger$Slf4jLogBackEnd [sdbe-compute-7] Detected Browser Firefox. Fallback?
Logger$Slf4jLogBackEnd [sdbe-compute-7] Detecting platform. Name is: {0}
Logger$Slf4jLogBackEnd [sdbe-compute-7] Detected Mac OS platform: {0}
Logger$Slf4jLogBackEnd [sdbe-compute-7] Detecting platform. Name is: {0}
Logger$Slf4jLogBackEnd [sdbe-compute-7] Detected Mac OS platform: {0}
Logger$Slf4jLogBackEnd [sdbe-compute-7] Using default search priority: {0}
Logger$Slf4jLogBackEnd [sdbe-compute-7] Executing search strategies to find proxy selector
Logger$Slf4jLogBackEnd [sdbe-compute-7] Using settings from Java System Properties
Logger$Slf4jLogBackEnd [sdbe-compute-7] HTTP proxy {0}:{1} found using whitelist: {2}
Logger$Slf4jLogBackEnd [sdbe-compute-7] HTTPS proxy {0}:{1} found using whitelist: {2}

proxy-vole interpreting IE settings differently

I noticed that proxy-vole interprets the settings read from IE differently, which might lead to non-working internet access in Java. And actually while trying to debug the problem, I got quite confused about this whole issue. I'll try to give a simple example that I encountered:

The setup in IE was set to manual, in the advanced settings dialog there was one proxy entered in the "socks" line (say 1.2.3.4:5678), all other fields left blank. Which made sense to me, it seemed IE would tunnel all connections, no matter which type, through the socks proxy. However, proxy-vole ends up in createFixedProxySelector, logs "IE uses manual settings: socks=1.2.3.4:5678 with bypass list: null"
so it goes ahead and add it via addSelectorForProtocol("socks" ...)

And this is where my confusion starts. As far as I can tell, proxy-vole's understanding of protocol in this regard is the protocol type that the java application requests when opening a connection. But in that context, socks makes no sense, because you never want to talk to a server using the socks protocol. And indeed, the proxy selector that gets generated on this computer never matches anything, because the URIs that get passed to the selector are mostly of type "http", "https" or "socket".

The next problem is that the proxy, if it would be returned by the selector, has type Proxy.Type.HTTP, which is also wrong, because that makes Java try to do a HTTP CONNECT after connection to the proxy, although it is a SOCKS proxy. So basically, proxy-vole interprets this IE setup as "if the client requests a connection of type socks (whatever that is), use the proxy server 1.2.3.4:5678 and talk HTTP CONNECT to it. For all other protocols, don't use a proxy." While IE interprets it as "for any outgoing TCP connection, use the proxy server 1.2.3.4:5678 and talk SOCKS to it."

So basically it comes down to that we generally talk about two different protocols: The protocol that the applications wants to talk to the server it is trying to reach, and the protocol that java should use when talking to the the proxy server. These two things seem to be mixed up in proxy-vole, but also in the IE settings dialog, because I cannot make sense of the list you see there: You get HTTP, Secure, FTP, Socks. So is this refering to the protocol that the browser is trying to talk, or the protocol that the proxy is talking? For HTTP and FTP, both would make sense; so I enter an http URL into the address bar, and expect IE to use the proxy server I entered in the HTTP line. But what protocol is it using to talk to the proxy? Transparent HTTP? HTTP CONNECT? SOCKS? No idea. I'd just assume transparent HTTP. For FTP, things get a little bit confusing; to my knowledge, there is no "distinct FTP proxy", so it could either use HTTP CONNECT or SOCKS. But you don't even have a way to say which type it is, you can only enter Host and Port. Finally if you get to the Socks line, things get confusing: This protocol makes no sense from the client's point of view, there is no socks:// URL type you could enter into your address bar. And we didn't even get to the point where you select "use the same proxy server for all protocols" -- what does that mean in that context, and which protocol is it using to talk to it? What is the difference to unchecking that option and just entering a socks proxy?

Sorry I cannot express this problem more clearly, I still hope it's possible to understand what I'm trying to get at.

Support for JNA 5 (java.lang.NoSuchFieldError: SIZE)

I'm getting this exception:

java.lang.NoSuchFieldError: SIZE
       at com.github.markusbernhardt.proxy.jna.win.WTypes2$LPWSTRByReference.<init>(WTypes2.java:42)

A web search on "java.lang.NoSuchFieldError: SIZE" points to cases where code built for JNA 4.5 being used with JNA 5. Proxyvole 1.0.5 depends on JNA 4.5.1. The problem is that when using other dependencies that require JNA 5, that version will be picked, probably causing the failure in proxyvole.

Would it be possible for proxyvole to upgrade to JNA 5?

NullPointerException in Proxy-vole 1.0.5

Hello,

a customer of mine is getting a NullPointerException in PacProxySelector#findProxy():

caused by: java.lang.NullPointerException
at com.github.markusbernhardt.proxy.selector.pac.PacProxySelector.findProxy(PacProxySelector.java:128)
at com.github.markusbernhardt.proxy.selector.pac.PacProxySelector.select(PacProxySelector.java:110)
at com.github.markusbernhardt.proxy.selector.misc.BufferedProxySelector.select(BufferedProxySelector.java:137)
at com.github.markusbernhardt.proxy.selector.misc.ProxyListFallbackSelector.select(ProxyListFallbackSelector.java:80)
at de.credo.lookup2.proxy.ProxyHandler.activate<ProxyHandler.java:282)

Relevant line in my program is:
data.proxyObject = proxySelector.select(new URI("https://license.cre-do.de")).get(0);

Program breaks at line 128 in PacProxySelector, which is:
String parseResult = this.pacScriptParser.evaluate(uri.toString(), uri.getHost());

Since given uri parameter is not null and valid by convention, only reason can be that variable pacScriptParser is null. (NPE is not in evaluate() method, so it's not able to call this method.) This variable in turn is set in PacProxySelector constructor with a PacScriptSource as parameter (PacProxySelector:41). This variable can only be null in case a JavaxPacScriptParser can't be created with this source.

To sum it up: A PAC script can't be evaluated by JavaxPacScriptParser and kills subsequent methods by not catching null. I'll try to get this PAC script, but this company may not be able or willing to give it out. Analysis of the PAC script can be the half solution only anyway.

Regards
Guido

BufferedProxySelector - Caching with individual URLs might not be ideal

Hi,

The below comment mentions that caching per host may produce wrong results. I am not sure about a scenario where we can expect wrong results with that. Please clarify if any such possible scenarios can exist, or would it be preferable to modify it to cache based on the host:port combination?

https://github.com/MarkusBernhardt/proxy-vole/blob/master/src/main/java/com/github/markusbernhardt/proxy/selector/misc/BufferedProxySelector.java#L89

NullPointerException if PAC method returns null

Hi Markus,

I found one more issue that if a null is returned from PAC file method, we end in NPE at com.github.markusbernhardt.proxy.selector.pac.PacProxySelector.findProxy(PacProxySelector.java:128).

As per the specification, a null is a valid return from method and it means that no proxy needs to be used. Please see if this can be fixed.

Thanks,
Pavan

JDK10 and proxy-vole

As proxy-vole has a dependency delight-nashorn-sandbox which is using com.sun.tools 1.4.2, maven compilation ends with Could not find artifact com.sun:tools:jar:1.4.2 at specified path. Is there any fix except for adding a dependency with system scope? (since it is in generla bad idea always).

StackOverflowError during Detection of Proxy from PAC in proxy-vole-20131209 & proxy-vole-1.0.5.jar

I'm getting the below exception while detecting Proxy from PAC file.

Currently, we are using the proxy-vole_20120920 jar to detect the proxy from PAC file As per current flow, after entering into NashornScriptEngine((Reader reader, ScriptContext ctxt) throws the exception.

As per this link , this bug was fixed proxy-vole-1.0.4.jar and it works but the same exception has occurred in proxy-vole-1.0.5.jar. Kindly recommend us "which version had a fix for this issue".

[13:42:30:868]|[01-10-2019]|[SYSERR]|[INFO]|[106]|[6c023c5c-8418-49a8-81c1-cf3bc47a6868]: javax.servlet.ServletException: java.lang.StackOverflowError|
[13:42:30:868]|[01-10-2019]|[SYSERR]|[INFO]|[106]|[6c023c5c-8418-49a8-81c1-cf3bc47a6868]: at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:295)|
[13:42:30:868]|[01-10-2019]|[SYSERR]|[INFO]|[106]|[6c023c5c-8418-49a8-81c1-cf3bc47a6868]: at org.apache.struts.actions.DispatchAction.execute(DispatchAction.java:170)|
[13:42:30:868]|[01-10-2019]|[SYSERR]|[INFO]|[106]|[6c023c5c-8418-49a8-81c1-cf3bc47a6868]: at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:425)|
[13:42:30:868]|[01-10-2019]|[SYSERR]|[INFO]|[106]|[6c023c5c-8418-49a8-81c1-cf3bc47a6868]: at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:228)|
[13:42:30:868]|[01-10-2019]|[SYSERR]|[INFO]|[106]|[6c023c5c-8418-49a8-81c1-cf3bc47a6868]: at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)|
[13:42:30:868]|[01-10-2019]|[SYSERR]|[INFO]|[106]|[6c023c5c-8418-49a8-81c1-cf3bc47a6868]: at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:449)|
[13:42:30:868]|[01-10-2019]|[SYSERR]|[INFO]|[106]|[6c023c5c-8418-49a8-81c1-cf3bc47a6868]: at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)|
[13:42:30:868]|[01-10-2019]|[SYSERR]|[INFO]|[106]|[6c023c5c-8418-49a8-81c1-cf3bc47a6868]: at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)|

automatic configuration evaluation error

Hi,
I'm getting errors when evaluating PAC script.

Caused by: jdk.nashorn.internal.runtime.ParserException: :8:2 Expected an operand but found else
else return "PROXY proxy:3128";
^
at jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:294)
at jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:279)

It's caused by semicolons before else , nashorn scripting engine doesn't like that.

` function FindProxyForURL(url, host)
{
if (shExpMatch(host, "deploy.abc.eu") ||
shExpMatch(host, "asp.abc.eu")
)

        return "PROXY proxy:3128";

    else if (dnsDomainIs(host, "localhost") ||
             dnsDomainIs(host, "127.0.0.1"))
return "DIRECT";
    else
    return "PROXY proxy:3128";
}`

Rhino scripting engine ( https://mvnrepository.com/artifact/org.mozilla/rhino/1.7.10 ) can evaluate this script correctly, what do you think about using it instead of nashorn ?

Slf4jLogBackend is not installed by default as documentation suggests

I noticed that there was no log output coming from proxy-vole even if I set my logging level to TRACE.

After minor inspection, I saw that the logging backend was null. There is no logging backend set by default.

I would argue that the Logger class should set the SLF4J backend by default. This is actually what the documentation says this library does.

NullPointerException at getProxySelector() with getDefaultProxySearch()

Thanks for continuing this project as a fork!

I'm trying to configure this without a maven project and have alle the necessary libs in my lib folder.

This is my code for testing:

// Register Logger instance 
com.github.markusbernhardt.proxy.util.Logger.setBackend(new LogBackEnd() {
	
	@Override
	public void log(Class<?> arg0, LogLevel loglevel, String msg, Object... params) {
		System.out.println(loglevel + "\t" + MessageFormat.format(msg, params));
	}
	
	@Override
	public boolean isLogginEnabled(LogLevel arg0) {
		// TODO Auto-generated method stub
		return true;
	}
});

// Use the static factory method getDefaultProxySearch to create a proxy search instance 
// configured with the default proxy search strategies for the current environment.
ProxySearch proxySearch = ProxySearch.getDefaultProxySearch();

// Invoke the proxy search. This will create a ProxySelector with the detected proxy settings.
ProxySelector proxySelector = proxySearch.getProxySelector();

// Install this ProxySelector as default ProxySelector for all connections.
ProxySelector.setDefault(proxySelector);

URI hostUri = URI.create("http://www.google.com");
System.out.println("ProxySelector: " + proxySelector); 
System.out.println("URI: " + hostUri); 
List<Proxy> proxyList = proxySelector.select(hostUri); 
if (proxyList != null && !proxyList.isEmpty()) { 
	for (Proxy proxy : proxyList) { 
		System.out.println(proxy); 
		SocketAddress address = proxy.address(); 
		if (address instanceof InetSocketAddress) { 
			String host = ((InetSocketAddress) address).getHostName(); 
			String port = Integer.toString(((InetSocketAddress) address).getPort()); 
			System.setProperty("http.proxyHost", host); 
			System.setProperty("http.proxyPort", port); 
		} 
	} 
}

Basically I just followed the example from your README file and added a logging method from this stackoverflow answer: http://stackoverflow.com/a/12604713/1128689

However, I always get a NullPointerException at proxySelector.select(hostUri) and it seems I ran into the same problem as two commentators at the stack overflow answer. proxySelector == null is true.

This might be related to #2, but it happens to me with your version 1.0.2 so I expect this to be fixed, right?

This is the logfile from my windows 10 system (no proxy configured):

TRACE	Detecting platform. Name is: Windows 10
TRACE	Detected Windows platform: Windows 10
TRACE	Detected Browser is InternetExplorer
TRACE	Executing search strategies to find proxy selector
TRACE	Detecting platform. Name is: Windows 10
TRACE	Detected Windows platform: Windows 10
TRACE	Detecting platform. Name is: Windows 10
TRACE	Detected Windows platform: Windows 10
TRACE	Detected Windows desktop
TRACE	Detecting system settings.
TRACE	We are running on Windows.
TRACE	Detecting IE proxy settings
TRACE	Autodetecting script URL.
INFO	No proxy found for desktop. Trying next one.
TRACE	Detecting IE proxy settings
TRACE	Autodetecting script URL.
INFO	No proxy found for IE. Trying next one.
INFO	No proxy found for java. Trying next one.
ProxySelector: null
URI: http://www.google.com
Exception in thread "main" java.lang.NullPointerException

Proxy-vole 1.0.5 not buildable with Java 10

Hello,

due to an dependency issue with javadelight-nashorn-sandbox it's not possible to build even proxy-vole 1.0.5 acutally on Java 10. File structure has changed since Java 9 and therefore a hard-wired system dependency to tools.jar can'T be solved any longer. It's working up to Java 8.

Here is the javadelight issue report: javadelight/delight-nashorn-sandbox#62

Regards
Guido

1.0.5 still not on Maven?

Markus,

version 1.0.5 is not available via Maven right now and version number in POM still is 1.0.5-SNAPSHOT. Is this correct?

Regards
Guido

StackOverflowError during Detection of Proxy from PAC

Hi,

I am facing issue when detecting Proxy from PAC.

it' seems a recursion that throws StackOverflowError occurs when library tries to handle proxy a big list from PAC file.

Exception in thread "Nashorn AST Serializer" java.lang.StackOverflowError
at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:209)
at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1877)
at java.io.ObjectOutputStream$BlockDataOutputStream.write(ObjectOutputStream.java:1841)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1534)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)

Please have a look at this : https://bugs.java.com/view_bug.do?bug_id=4152790

I've Already debug it seems PacScriptParser interface's evaluate method calls NashornScriptEngine's

public Object eval(String script, ScriptContext ctxt) throws ScriptException method which causes all of errors i guess.

Is there any chance to support, bugfix or workaround for this issue?

Regards,
Alican

Proxy-vole provoking sporadic crashes in ntdll

Using the proxy-vole library to do the proxy autodetection, it resulted in crashes while using the app. Furthermore, this only happened only the app was ahead-of-time precompiled with Excelsior JET. With the great help from the guys at Excelsior, they managed to isolate the issue as they describe below.

Problem:
The proxy-vole library (proxy-vole-1.0.4.jar) has an issue provoking sporadic crashes in ntdll

Detailed description:

Specifically, it is in the com.github.markusbernhardt.proxy.jna.win.WTypes2#LPWSTRByReference class.

The default constructor of the class (through a chain of calls) allocates native memory with malloc BUT the allocated memory chunk is NOT zeroed so it contains undefined values.

Then, depending on execution path, the memory is either left intact or a pointer to a Windows system structure is stored there by a system call. In the latter case, Kernal32.GlobalFree() should be invoked later to free memory occupied by that Windows structure. This is implemented in LPWSTRByReference.finalize()

However, the finalizer cannot distinguish uninitialized (non-zeroed memory) from a pointer to the structure and always invokes GlobalFree, if the stored value is not null (0, zero, nil, you name it).

This provokes crashes in ntdll.

Appearance of the problem is volatile because GlobalFree is invoked from a finalizer, which, in turn, can be invoked at different moments of execution or not invoked at all.

Under Oracle JRE, the problem exists but does not appear due to a different order of invoking finalizers (the Java spec does not impose any particular order on it).

Fix:
A simple patch would be adding memory cleanup in the LPWSTRByReference constructor, which is added in the PR.

Failed to find SOCKS proxy with Java search strategy

The Java Search strategy stops setting up the ProxySelector object when the property http.proxyHost is not set. That means if only socksProxyHost is set the search strategy will not create a selector for it.

I believe the guard checking the availability of the proxy properties should check for the presence of either of these properties.
I can provide a patch if that is desired.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.