Whitelisting Trusted IP Ranges
UPDATED: 6 March 2009
It turns out that the code I originally wrote for this post became obsolete. I don't know exactly when this happened but I have come up with a fix. My apologies to anyone that may have tried the original code only to see that it didn't work. Please try this new code, it should work just fine.
I suppose I should shed some light on what happened. For some reason salesforce.com added a _CONFIRMATIONTOKEN variable to the network access page. That variable seems to be generated when the page is accessed. I won't pretend to understand exactly what it is or how it works but I will tell you that in order for me to get the IP ranges to actually save through this sControl I needed to capture that variable from each page where I perform the update and then use it to force Salesforce to commit the save.
As you can imagine, this reloading of many IFRAMEs can be a burden on the browser so be patient when you run the code. I incorporated better logic into the status column for each IP update to actually inform you if the update works or doesn't. Let's be honest, all of this work in the browser can do some funky things and sometimes a few of the IP ranges don't update as intended. Therefore, you will either need to run the sControl again or manually enter any of the ranges that fail after the initial run.
Thanks to Sonny Cloward for pointing out that the code was not performing as intended. I appreciate the feedback and hope that anyone who comes across this code might find it useful.
As you know, salesforce.com has taken many steps to ensure that their app is secure. The primary security features call for the use of a security token appended to the standard Salesforce login credentials or a confirmation message to enable login from specific computers/laptops. For most Salesforce customers these security features were a welcomed addition but to developers these security features caused some headaches.
Developers will often create a one-off Salesforce org to demonstrate some functionality that they have built or for illustrative purposes to assist with things such as training or sales. Without side-stepping the security features a developer will often have to begin a presentation with the instructions for getting through the Salesforce security and this makes for some unwanted downtime especially if the demonstration is with a prospective customer.
One of the ways to get around the security features is to list out specific IP addresses or IP ranges that have permission to access your org. Using the Salesforce app anyone with admin rights can go in and enter IPs that are trusted but the process is very manual. It would be easier to use the Salesforce API to load in a bunch of IP addresses directly into the table where this information is stored. However, the table for trusted IPs is currently unavailable via the API and that leaves only one way to get the IPs listed - manually.
When trusted IP functionality was initially released, salesforce.com allowed admins to simply enter the full range of possible IP addresses in one entry (0.0.0.0 through 255.255.255.255). This single entry was simple to make and didn't require more than a few seconds to setup. However, the app now limits the size of the IP range that can be entered and that means that the admin now has to create multiple entries to cover the same range (0.0.0.0 through 255.255.255.255).
Initial Trusted IP Functionality
Current Trusted IP Functionality
To be clear, most companies will not need to make trusted IP entries because they want to fully utilize the security features of the Salesforce application. But companies that sell AppExchange products will certainly need to add the full list of trusted IP ranges because they want to ensure that all people willing to demo their app can access it from wherever they might be on the planet. For this reason I decided to put together a simple sConrol that when accessed will populate the full range of possible IP addresses for an org. I use this sControl every time I create a developer edition org and when we create demonstration apps for our customers or for demos on the AppExchange. The full code is below:
This code takes a minute or so to run completely but this is a short time period when compared to entry after entry that would need to be made in the trusted IP ranges table manually. Since the code only needs to be run once you can simply delete it after running the first time.
As always, you are welcome to send any questions directly to me using the email address listed at the bottom of this post or you can always contact my whole team by using the contact us page on this website.