Salesforce Etiquette: Excusing One’s Self from the Subdomain of a Managed Package
Happy New Year boys & girls! In preparing a new version of an app I released on the AppExchange I came across the interesting problem of needing to excuse myself from my managed package subdomain in order to dynamically grab the content (using the native getContent() method) of a visualforce page that may or may not exist within the package itself.
As you may have noticed previously the standard subdomain for a visualforce page is c.XXX.visual.force.com where XXX refers to your particular salesforce server (na1 for example). On the other hand, when accessing a visualforce page that exists within a managed package the subdomain looks more like NameSpace.XXX.visual.force.com where NameSpace refers to the pre-defined namespace prefix of the managed package.
Normally this is irrelevant from a user’s standpoint, but in my case I needed the Apex controller extension for a managed visualforce page to grab the content of a visualforce page defined within Custom Settings. This means, depending on the settings, the page might exist within the managed package itself or it may be a custom page created solely within an individual Salesforce org. The latter case can cause a problem since when defining a new PageReference using partial URLs the current subdomain is maintained by default.
Well, as it turns out I discovered the solution to this problem is actually quite simple. You can treat any pages outside of your package as if they belonged to a managed package with a namespace prefix of “c” In hindsight this seems obvious given the structure of the standard subdomain of a visualforce page. Many thanks to @jhart from the Force.com discussion boards for pointing me in the right direction with the last post from his thread.
Here’s a snippet of code you could use within an Apex class to accomplish this functionality (You’ll notice I only grab the content when the class is not running within the context of a test — this is because the getContent() method is not allowed within a test context):
Hope this helps someone, happy coding!
Protect Your Org.
Secure Your Data.
Salesforce security is a shared responsibility. Don't try to solve it alone.
Salesforce Updates and Guidance
Explore expert strategies and practical advice on Salesforce security and permissions