Proxy .PAC file no longer works

I can confirm that this bug exists. My .pac proxy file is also failing.

var tests = [         '*.local',         '*.local.nz',         '*.local.au',         '*.fws'     ],     direct = 'DIRECT',     proxy = 'PROXY webserver:80'; var FindProxyForURL = function (url, host) {     var i = 0;     for (i = 0; i < tests.length; i = i + 1) {         if (shExpMatch(host, tests[i])) {             return proxy;         }     }     return direct; };

same victim here, and a similar topic below

Safari 5.1 ingores .pac file

https://discussions.apple.com/thread/3194478?answerId=15731770022#15731770022

Local PAC will not work bc of the sandbox mechanism in Lion.

Using a remote (http://) should be fine.

Thanks for the info about the sandboxing. Putting the proxy on the remote sever does work, but that means ALL my requests have to go to the remote sever first, and I only want a few select sites to go that way instead. Temporarily, I enabled web sharing, and placed the .pac file on http://localhost/proxy.pac , which works too.

Also note that there is a discrepancy between the fact that the pac file is supposed to be on a http:// site, and yet there is still the "Choose File" button, which opens the local drive.

nice and neat, i am going to do the same

thanks a bunch!

I see we have a workaround but is this considered a bug and is Apple planning on fixing it?

I ask this because the wizards at my company use an applet from Juniper Networks to implement their RSA based secure VPN. In their zeal for security, they thought they'd copy the PAC file locally upon VPN connection. I can only assume that they hoped to increase the performance of browser connections.

Yet, by bypassing the traditional commands to set proxy and forcing their choice on the system, any browser that uses the system proxy settings are hosed - that means Safari. Yes, it was a well-intentioned but poorly thought out configuration decision.

The question now is - do I have to wait some period of months until the wizards at my company fix their mistake? or is this a bug that Apple will be fixing in a few weeks?

I am pretty sure the .pac file is not downloaded for every request (that would be insane). More than likely it is downloaded and cached periodically (perhaps when the browser first starts up). So running it on a localhost web server should not be required.

I agree this seems like a bug, at the very least Apple should warn you when it detects a local proxy pac if it's really not "supposed" to work any more.

Hello,

I found a workaround to this issue that doesn't involve having to install your pac file on another web server, nor activating web sharing on the local system.

First, a little more background on what I found:

After configuring my system to use a local .pac file (in my case, "proxy.pac"), I took a look at my console log messages, and found the following:

07/09/11 12:21:25.721 AM sandboxd: ([82829]) WebProcess(82829) deny file-read-data /Users/tfischer/Documents/scripts/proxy.pac

Ok - so this just confirms that the sandboxing of Safari 5.1 is preventing the WebProcess daemon from accessing the proxy.pac file.

However, Safari does a lot of stuff, and it has to be able to read some files (plugins, etc.), so the trick is to put the pac file somewhere that WebProcess can access.

After rooting around a bit, I found that there are sandbox definition/configuration files for various processes and apps in /usr/share/sandbox. These files end in ".sb", and they define all sorts of things - what files can be read, written, etc. Unfortunately, the sandbox definition file for WebProcess doesn't live in /usr/share/sandbox. Searching a little bit further revealed that the sandbox definition file is here:

/System/Library/PrivateFrameworks/Webkit2.framework/WebProcess.app/Contents/Reso urces/com.apple.WebProcess.sb

I initially thought about modifying the file to tell it that it could read /Users/tfischer/Documents/scripts/proxy.pac (with a couple lines like the following:

(allow file-read-data

(home-literal "/Users/tfischer/Documents/scripts/proxy.pac"))

but after some reflection, I decided that this wasn't a good idea: even if the modified com.apple.WebProcess.sb file worked, my changes would be wiped out the next time that Safari was updated.

Further examination of the file showed that WebProcess has read access to the "/Library/Internet Plug-Ins/" directory. So, I copied my pac file into "/Library/Internet Plug-Ins/proxy.pac", modified my network preferences to reflect the pac file's new home, and restarted Safari.

After doing this, Safari was able to use the local pac file again...

I hope this helps!

best regards,

tom

Wow, excellent findings! this workaround looks much better than enabling the web server, gonna try it later when i get home

thanks Tom

I put my pac in web sharing and and I can check it is in place from browser URL: http://localhost/~username/myhttpproxy.pac OK.

But it does not work. How to troubleshooting?

My pac file is very simple:

function FindProxyForURL(url, host) {

if(shExpMatch(url, "*.facebook.com/*") )

{

return "PROXY <IP>:80";

} else {

return "DIRECT";

}

}