What steps will reproduce the problem?
1. Bundling proxy-vole in a WebStart application
* signed with a vaild keystore that is trusted by an official CA
* runs with permissions "all-permissions"
2. Deploy application on a distinct server (on localhost it seems to work)
3. Start the application via its JNLP file over a SSL secured connection
(without SSL it definively works!)
What is the expected output? What do you see instead?
The PAC script is detected and should be exectued but instead an
(Security-)Exception is thrown on calling the "myIpAddress()" from within the
PAC script code.
What version of the product are you using? On what operating system?
* current trunk version (r158) of proxy-vole
* Windows 7
* Java 8 (with Java 7 it works)
* SSL secured connection (with plain HTTP it works)
Please provide any additional information below.
It seems that in Java 8 under the described circumstances the calling
JavaScript code in the PAC script does not have the privilege to call the
System.getProperty(OVERRIDE_LOCAL_IP) and
NetworkInterface.getNetworkInterfaces() methods anymore, that are invoked
during the call of PacScriptMethods.myIpAddress().
Solution proposal
I propose to encapsulate the call to the method getLocalAddressOfType(...)
(from myIpAddress() and myIpAddressEx()) in a PrivilegedAction and call that
with AccessController.doPrivileged(...) in order to restore the original
granted privileges of the code (and not running with the reduced privileges
from the calling JavaScript code).
Please see the attached version of PacScriptMethods including following
modifications:
* Calls to getLocalAddressOfType(...) are wrapped in PrivilegedActions (as
previously described)
* The IP-Adresses are cached, since each call takes about 2s on my machine and
some PAC scripts call this method quite ofen (> 10 times)
* Before all network interfaces are looked up to determine the IP address, the
first step is to try to resolve the localhost's IP address using
InetAddress.getLocalHost() (like you did in older versions). This is required
since it often delivers better results than the scan for the network
interfaces, which delivers an abitrary order of all interfaces ( this resulted
on some machines on returing 192.168.x.x addresses).
Original issue reported on code.google.com by daniel.w...@gmail.com on 24 Apr 2015 at 7:49
Original issue reported on code.google.com by
daniel.w...@gmail.comon 24 Apr 2015 at 7:49Attachments: