Proxy .PAC file no longer works

I Originally used this method and packaged it up creating a pkg with Jamf Composer.

https://discussions.apple.com/thread/4138324?answerId=19045147022#19045147022

I Was then able to update from Safari 6.0.3 to 6.0.4 and keep the proxy work around. Unfortunately it didn't work and I have entries firm my proxy PAC file.

I will try you entry method instead and see if it works.

thanks for your help Tom it very useful, unlike another thread in the Safari discussions where a guy is saying repair permissions, boot to recovery disk lol. I'm ok because I'm a unix geek but feel sorry for the suckers spending hours following that screwy advice.

Well, the Security Update 2014-002 from April 22, 2014, again moved the sandbox file that needs to be modified in order to use a local proxy.pac file with Safari. I was able to get my local proxy.pac configuration working again by modifying the following file:

/System/Library/PrivateFrameworks/WebKit2.framework/Versions/A/Resources/com.app le.WebKit.NetworkProcess.sb

I inserted the following line in red to line 53 of the file:

____________________________________________

;; System and user preferences

(literal "/Library/Preferences/.GlobalPreferences.plist")

(regex #"^/Library/Managed Preferences/[^/]+/com\.apple\.networkConnect\.plist$")

(home-literal "/Library/Preferences/.GlobalPreferences.plist")

(home-regex #"/Library/Preferences/ByHost/\.GlobalPreferences\.")

(home-regex #"/Library/Preferences/ByHost/com\.apple\.networkConnect\.")

(home-literal "/Library/Preferences/com.apple.DownloadAssessment.plist")

(home-literal "/Library/Preferences/com.apple.WebFoundation.plist")

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

____________________________________________

tom

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; };

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.

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

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";

}

}

Same problem here with proxy.pac but we have always used it from a remote web server. The same URL we have used for all our Windows XP, Win7, 2003 and 2008 machines along with out Mac OS X 10.4 and 10.6 machines no longer works with 10.7.

We are using 10.7.2 and Safari 5.1.1 I believe - whatever the latest version are as of 3 days ago.

Any resolution on this?

Found a Solution the the .PAC problem. Webservers don't like serving up PAC files so if you are hosting it on a webserver somewhere and not locally on your iPad then you need to change the PAC file into a standard text file. This can still be read by the iPad as a PAC file but the webserver is happy to serve it up.

Problem Solved.

Looks like the readable folders have changed with Mountain Lion's release. After upgrading to 10.8, the proxy rules weren't working, so using Tom's same search method, you can browse which files are accessible in /system/library/privateFrameworks/webkit2.framework/webprocess.app/contents/res ources/com.apple.WebProcess.sb, and move your .pac file there. Works now for me with Safari 6.

Following up on my own post:

As of Safari 6.0.2 (at least under Mac OS X Mountain Lion 10.8.2), the sandbox configuration file for Safari has moved. The new sandbox file is found at:

/System/Library/StagedFrameworks/Safari/WebKit2.framework/WebProcess.app/Content s/Resources/com.apple.WebProcess.sb

best regards,

tom

Hi Tim,

The proxy.pac issue has been around since Safari 6.0 with the sandboxing feature. In version 6.0.4, the sandbox file was overwritten with a new one (exactly the same as version 6.0.3), in the same directory as for version 6.0.3, located at:

/System/Library/StagedFrameworks/Safari/WebKit2.framework/WebProcess.app/Content s/Resources/com.apple.WebProcess.sb

You either need to look in this file and find a directory that Safari has been given read access to, and put your proxy.pac file in there, or add another line containing your proxy .pac filename and location to the "allow file-read*" list. This section starts at line #21 in the file, and looks like:

————————————————

;; Read-only preferences and data

(allow file-read*

;; Basic system paths

————————————————

Using my own setup as an example, I edited the file, and added the following lines at around line #35 of the file:

————————————————

;; Added by Tom for proxy.pac

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

————————————————

While waiting for Apple to fix this, I've been using the above as a reliable workaround since the release of verion 6.0...

best regards,

tom