Find your content:

Search form

You are here

Winter 13 Clickjacking protection - is the following expected or a bug?

 
Share

Here are the steps to reproduce on a Winter 13 sandbox:

Create the following VisualForce component called TestClickJackComponent:

<apex:component >
<!-- Begin Default Content REMOVE THIS -->
<h1>Congratulations</h1>
This is your new Component
<!-- End Default Content REMOVE THIS -->
</apex:component>

Create the following VisualForce page called TestClickJack:

<apex:page StandardController="Lead">
<!-- Begin Default Content REMOVE THIS -->
<h1>Congratulations</h1>
This is your new Page
<!-- End Default Content REMOVE THIS -->
<c:TestClickJackComponent />
</apex:page>

Add the page to your lead page layout. You'll see:

Congratulations This is your new Page Congratulations This is your new Component

Now go to Enable Setup-Security Controls – Session Settings and select Enable clickjack protection for non-setup customer Visualforce pages

Now you'll see:

URL No Longer Exists You have attempted to reach a URL that no longer exists on salesforce.com.

So, my question is - is this a bug? Or is it expected behavior with the new clickjacking protection?


Attribution to: kibitzer

Possible Suggestion/Solution #1

I would assume with click-jacking that SFDC URLs are white-listed. However, because all browsers enforce cross origin policies, click jacking should only be an issue between pages on the same domain and iframe.

However, it could be that standard pages are on a different domain than custom VF page domain.

So, I just did something similar, dropped a VF page with a standard controller Lead onto the lead layout:

Enable clickjack protection for non-setup Salesforce pages - no issues

Enable clickjack protection for non-setup customer Visualforce pages - same error: URL doesn't exist.

Seems like the 2nd option (checked with or without both) causes this error: So it looks like it's stopping the iframe from accessing VF pages when the 2nd option is checked, which I would assume is the expected behavior


Attribution to: jordan.baucke

Possible Suggestion/Solution #2

Have received further reliable information from Salesforce.

This is the expected behavior, at least for now. They will be looking into it further.

The workaround is to be sure to set ShowHeader = false on the page tag for the VisualForce page.

From my perspective, the real failure here is in communication. A failure to make it very clear in the documentation and release notes that this problem does apply to Visual Force pages on page layouts, a failure to clearly document the workaround (it's not even mentioned in the release notes), a failure to give organizations and ISVs lead time that this issue was coming so they'd have time to validate code and put in the necessary updates before user's turn on this feature an go into a panic when everything breaks. A failure of the support organization (I opened a case and got back that this was a "feature" - but without any note of the workaround).


Attribution to: kibitzer
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/1387

My Block Status

My Block Content