Over the years, we have gone from a pretty standard looking Salesforce community to a pretty custom community. We had standard pages everywhere, standard page layouts and tabs that our Partners and Customers would use to navigate our site.
With the implementation of a new design and a new template to take our Community to a new level came with some challenges. We overwrote all of the standard pages for custom pages that match our company brand and colors and updated usability. Unfortunately, users of our site who knew it was Salesforce based could use their knowledge of Salesforce and get around some of the overwrites we had done. For example, if you know the first 3 digits of a record, you can URL hack to get the Tab of that object:
https://communityURL.force.com/communityname/001/o
If you plug in your community info into this pattern, you will get to an Account tab page with the standard community branding that you set up at the time of community creation. Accounts may make sense, but what about Contacts, or Leads or any of your Custom objects that you don’t think or know if your Partners have access to any of the data, but they might or probably do.
You may also be thinking, ‘Hey! I can just overwrite the Tab page on each object and direct an internal user to the standard Tab and a Community user to an error page!’. You are mostly correct. However, did you know you can also access the Tab without the ‘/o’ at the end? Did you also know this isn’t redirected by overwriting the standard Tab?
https://communityURL.force.com/communityname/001
If someone knows this, the redirect you just built will not catch this case and the user will be able to see the Tab still. Kind of a bummer.
I went to Twitter to see how other folks have done this in the past and was pleasantly surprised by the quick responses:
It turns out, there is a new feature in API v.39 that allows you to specify at the site level if the site can show any standard pages. For me, this is exactly what I wanted because we don’t have any standard pages anymore and want to prevent someone from ‘accidentally’ getting to a standard page that shows them things I don’t want them to see.
https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_sites.htm
We know that it can be done, but if you go to the Site setup page, there isn’t an option to prevent standard pages as a checkbox. That sucks! So how does one go about making this change?
Now we get into the fun stuff.
Open up your favorite IDE connected to Salesforce (or create a package.xml file to do this manually) and include CustomSite into your project.
Make sure to refresh your project to pull down all of the sites you might need. Then, make sure you are using at least API v.39 as any version before will not know about the feature called ‘allowStandardPortalPages’. Open your site you want to make this change for and add the tags and a boolean value of true or false.
Save that baby and give it a test. When you log in as a Partner user and try to navigate to the standard Account tab page, either ‘/001/o’ OR ‘/001’ you will be denied access and shown the standard Salesforce URL not found page.You will also be denied access to any other standard page regardless of how you got there. Not ideal, but better than showing the standard page.
Now all you need to do is do a bit of testing to make sure you aren’t forgetting about a standard page that Steve or Larry made part of your org for a long forgotten but sometimes used process to make sure everything is still going to work. After that, deploy that thing and you won’t have to worry about Partners (or even Customers maybe) accessing standard pages.
Special shoutouts to Peter Churchill and Daniel Hoechst for knowing about this and alerting me and others to this magic!
Watchforce 