7

After activating the Critical Update, I checked a couple of my orgs using Managed Packages which provide resources used on buttons and scripts in the Standard Salesforce domain. It surprised me that they still do work. Although I'm very happy, I would like to understand the Critical Update.

So lets say I have a static resource called core_js provided by an Package with prefix pack123 I use the following relative URI in a custom (javascript) button to load the resource:

/resource/1402932484000/pack123__core_js

This works fine with and without the Critical Update. Note that against "best practice" I'm not using $Resource or URLFOR() since in plain JS context they are simply not available. The relative URI above will be translated into an absolute URI in my case on the pod EU3

https://eu3.salesforce.com/resource/1402932484000/pack123__core_js

This is because I include the resource with a relative path from the Standard Salesforce Domain - not from inside the package itself.

My understanding of the Critical Update was, that it will break the code, since the resource should be only available via

https://pack123.eu3.visual.force.com/resource/1402932484000/pack123__core_js

But this is (luckily!) not happening. The resource is still (after) activating the Update available via both absolute URIs. So is my understanding of the Critical Update wrong? It says at it's Impact Detail section:

Prior to the Winter ’15 release, some static resources, such as images and CSS files, were loaded from the Salesforce Domain. This update changes that behavior so that all static resources are loaded from the Visualforce Domain. This change to the origin domain can cause absolute references to static resources to break.

It’s a best practice to reference static resources by using the $Resource global variable and the URLFOR() function instead of static strings. For example:

<apex:includeScript value="{!$Resource.MyJavascriptFile}"/>
<apex:image url="{!URLFOR($Resource.TestZip, 'images/Bluehills.jpg')}" width="50" height="50"/>

These references are safe to use regardless of your organization’s settings for this Critical Update.

We recommend that you test this update in a sandbox or Developer Edition organization to verify correct behavior of your pages before enabling it in your production organization.

Is there a reproducable example of something what is actually broken by the activation of this Critical Update?

Does anyone anticipate the reason behind this Critical Update? What Salesforce is going to achieve with it?

1 Answer 1

6

It looks like Salesforce is currently doing 302 redirects for static resources requested from the salesforce.com domain when the security update is enabled. I didn't notice the redirect behavior until this morning, and was reasonably confident that we were getting 404's before. Turning the security update back off results in HTTP 200 instead of the 302 redirect.

Salesforce doesn't have any documentation regarding the redirect behavior. In their extremely limited documentation on the topic ( http://releasenotes.docs.salesforce.com/en-us/api_cti/release-notes/rn_vf_static_resources_visualforce_domain_cruc.htm ), they say "This change to the origin domain can cause absolute references to static resources to break", but that is clearly not the case currently.

Edit: One thing that is absolutely broken (with or without the redirect working) is AJAX requests to static resources, such as pulling down a JSON document you have hosted there. Because it is now a redirect to the force.com domain, it becomes a cross-domain request and force.com doesn't set CORS headers for it.

1
  • I am getting this redirect problem as well trying to get a STatic Resource file with Apex - any solutions out there?
    – DevilCode
    Dec 1, 2014 at 14:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .