{"id":34,"date":"2008-01-21T23:56:41","date_gmt":"2008-01-21T23:56:41","guid":{"rendered":"http:\/\/installingcats.com\/2008\/01\/21\/xmlhttprequest-permission-denied-fix-salesforcecom-ajax-toolkit\/"},"modified":"2008-01-21T23:56:41","modified_gmt":"2008-01-21T23:56:41","slug":"xmlhttprequest-permission-denied-fix-salesforcecom-ajax-toolkit","status":"publish","type":"post","link":"https:\/\/installingcats.com\/2008\/01\/21\/xmlhttprequest-permission-denied-fix-salesforcecom-ajax-toolkit\/","title":{"rendered":"XMLHttpRequest permission denied fix – Salesforce.com Ajax Toolkit"},"content":{"rendered":"

Update: This post has been superseded by How to Fix Ajax Error: permission denied to call method XMLHttpRequest.open<\/a>.<\/p>\n

For anyone developing S-controls and applications for use in Salesforce.com, developing directly within their platform is a bit of a hurdle. Using their Ajax Tools Development Environment for quick changes is fine. But, developing a serious piece of code purely using that tool is far from a pleasant reality today. Hence its natural to develop on a local machine then upload to Salesforce.com when a piece of software is ready for testing within the platform.<\/p>\n

When trying to use the Ajax Toolkit connection.js library locally, you\u2019ll encounter a cross domain scripting error:<\/p>\n

\u201cPermission denied to call method XML<\/span>HttpRequest.open\u201d<\/h2>\n

Cross domain scripting is not allowed by default in Mozilla based browsers (Firefox, Camino, etc.).<\/p>\n

To override this security feature you need to add the following line to your XML<\/span>HttpRequest code before issuing an open() call:<\/p>\n

netscape.security.PrivilegeManager.enablePrivilege(\u201cUniversalBrowserRead\u201d);<\/p>\n

This allows the user agent (browser) to ignore cross-domain scripting warnings, which are a major source of cracking attacks<\/a>.<\/p>\n

There are one or two more steps required to make this work depending on whether you’re using Firefox or Camino. The following step is the same for any Mozilla borwser, be it Firefox, Camino, or any other Mozilla based web browser agent.<\/p>\n

In the browser address window type:<\/p>\n

about:config<\/p>\n

This opens the Mozilla configuration file which you can filter using the field at the top of the screen and edit items by double clicking on them.<\/p>\n

Find signed.applets.codebase_principal_support
\n\"Top
\nBy default it should be set to false. Double clicking it should set it to true.<\/p>\n

For Firefox users, this next step is also necessary: adding a capability.policy line to the user.js config file which contains all user preference settings for the browser. Regardless of which operating system you’re using, user.js does not exist by default<\/i>. Therefore, you must create this file, then add the appropriate settings into it. The settings from user.js get copied to prefs.js, which is the actual file read by Firefox.<\/p>\n

On Mac OS X the correct directory to create this file within is:<\/p>\n

~\/Library\/Application Support\/Firefox\/Profiles\/[alphanums].default\/<\/p>\n

On Win XP or 200:
\nC:Documents and Settings[User Name]Application DataMozillaFirefoxProfiles<\/p>\n

See this Mozilla page on Editing config settings for more details and examples on locations for this file.<\/a><\/p>\n

Note that [alphanums].default is a jumble of letters and numbers “dot” default and it is a directory<\/b>. For example “o3dfi34z.default”. Within this directory<\/i> create a file named “user.js”. Within this file add the following three lines:<\/p>\n


\nuser_pref(\"capability.policy.XMLHttpRequestToAnySite.XMLHttpRequest.open\", \"allAccess\");
\nuser_pref(\"capability.policy.XMLHttpRequestToAnySite.sites\", \"http:\/\/localhost.com:3000\");
\nuser_pref(\"capability.policy.policynames\", \"XMLHttpRequestToAnySite\");
\n<\/code><\/p>\n

Now note that “http:\/\/localhost.com:3000” is only in my case. Whatever your local development location is, use that, be it “http:\/\/localhost”, “http:\/\/192.168.1.1”, etc. etc., use that. Be exact with this site address<\/i><\/b>. It matters. For me, that port number was required for Firefox to allow me to send XMLHttpRequests to another domain without being denied.<\/p>\n

Try running the XML<\/span>HttpRequest again and hopefully your Permission denied to call method XML<\/span>HttpRequest.open error has disappeared.<\/p>\n

For those of you trying to use the Salesforce.com connection.js Ajax library locally, these are the following edits I made to make this happen. The following line numbers relate to version 11.1 of connection.js.<\/p><\/div>\n

Find the definition of sforce.Transport<\/code>, which should be around line 565.
\nFind the line: this.connection.open(\"POST\", this.url, async);<\/code> around line 591.
\nAdd the following line before<\/i><\/b> the previous line:
\n
\nnetscape.security.PrivilegeManager.enablePrivilege(\"UniversalBrowserRead\");
\n<\/code><\/p>\n

Change the relative URL paths for the Salesforce API from “\/services\/Soap\/u\/11.0” to the following:
\n
\n\"https:\/\/www.salesforce.com\/services\/Soap\/u\/11.1\"
\n<\/code><\/p>\n

A nice way to do this is simply add a constant at the top of connection.js and just replace all occurrences of the relative path with this constant:
\n
\nconst sforce_api_url = \"https:\/\/www.salesforce.com\/services\/Soap\/u\/11.1\"
\n<\/code><\/p>\n

After that, fire up your trusty browser and try making your Ajax Toolkit call again.<\/p>\n

You may find it helpful to use a Javascript development environment like Jesse Ruderman’s Javascript Development Environment 2.0.1<\/a> when playing around with Javascript. [Jesse, you’re the man]. Install it as a bookmarklet for the best user experience. It allows you to access all the javascript code and the document model in your current browser window through this development environment (which opens up in a new window).<\/p>\n

Don’t forget the about:config stuff with the browser up above.<\/p>\n

And finally, this is for debugging purposes on your local machine. Don’t publish code which disables security settings (which are there for a good reason) to a live deployment environment<\/b>, such as Salesforce.com. Normally you’ll be installing the code you’re building as an S-control anyways, within the Salesforce.com platform, which will be exempt from any cross-site cross-domain scripting issues.<\/p>\n","protected":false},"excerpt":{"rendered":"

Update: This post has been superseded by How to Fix Ajax Error: permission denied to call method XMLHttpRequest.open. For anyone developing S-controls and applications for use in Salesforce.com, developing directly within their platform is a bit of a hurdle. Using their Ajax Tools Development Environment for quick changes is fine. But, developing a serious piece […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10,2],"tags":[80,81,82],"_links":{"self":[{"href":"https:\/\/installingcats.com\/wp-json\/wp\/v2\/posts\/34"}],"collection":[{"href":"https:\/\/installingcats.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/installingcats.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/installingcats.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/installingcats.com\/wp-json\/wp\/v2\/comments?post=34"}],"version-history":[{"count":0,"href":"https:\/\/installingcats.com\/wp-json\/wp\/v2\/posts\/34\/revisions"}],"wp:attachment":[{"href":"https:\/\/installingcats.com\/wp-json\/wp\/v2\/media?parent=34"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/installingcats.com\/wp-json\/wp\/v2\/categories?post=34"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/installingcats.com\/wp-json\/wp\/v2\/tags?post=34"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}