function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Alex ZagvazdinAlex Zagvazdin 

How to get an AppExchange application IP address whitelisted in the Salesforce.com

Hi,

We have recently developed an integration for our online application with the Salesforce.com. The application requires user's Salesforce.com username and password for the integration. However, recently Salesforce has introduced Security Token which is absolutely not user friandly especially for new users who register for a free trial with our tool.

So the question is, is it possible to get the IP addresses of the servers where our application runs whitelisted to the Salesforce.com, so when the new users want to try out our integration with Salesforce they won't need to go through the annoying procedure of obtaining a security token? Is there a some sort of a partner program that allows doing that?

Any help would be greatly appreciated.
colingcoling
I have the same problem.

My published composite app requires salesforce.com login credentials to work. I am finding that just requesting new (trial) users to whitelist my server's IP address is not sufficient - for whatever reason they are not doing this. It's another step of complexity that easily gets in the way of prospects trying out the app.

What I would like to have is the ability to add an IP address, via the API, to the whitelist - when the user is already logged in to salesforce.com of course and during the process of registering for my app. I see this as an effective solution. Of course it should be available through the API, including PHP (which is another story)

As far as I can see, this is the only way to go - relying on the prospect is not.

Colin Goldberg
sfdcfoxsfdcfox
A composite app should be able to use the {!$Api.Session_ID} merge field to obtain access to the client's Salesforce database without login credentials or a security token. In this context, I find it hard to justify the use of login credentials, or an API call to automatically whitelist the address you've logged in from (which requires a token to begin with). The exception to this above policy is if your compose application plans on visiting some hours later, in which case it does require credentials, and therefore a token. However, I'd guess that you probably simply need to use the session ID merge field.
Alex ZagvazdinAlex Zagvazdin
WThanks for the answer, but the probelm is that our application does not always work within the same session with the user. It actually has to update some data in Salesforce when the user may not be logged in.
colingcoling
In my composite app, there is a need to log in via the api hours/days/weeks later. So the initial session id does not apply, and cannot be used by the background job that later logs in.

Taking the path of whitelisting the IP address of my server means that there is no code change needed in the background job - it would log in as it has been doing in the last few months. Taking the path of using the new token would definitely require a code change. So I would like to ensure that the IP address is whitelisted - preferably at the time the customer installs the app.

I have a wizard which takes the customer through a 'registration' process after the salesforce.com installation process has completed. So here I can rely on the fact that the user is logged in, and therefore the session id is available. I have recently added a step in the wizard (ie. a page) that asks the user to go to Setup and insert my server IP address (I give detailed instructions) before continuing. But at this time I am completely dependent on the user, and I have no way of knowing that this has actually been done. So if the user does not follow the instructions, and my IP address is not whitelisted, my first background job will fail to log in. I am then faced with the tedious - and failure-prone - task of getting the user (by phone, email, etc.) to whitelist the IP address. This is an unacceptable solution to the problem.

So what I would like to have available is the ability to add my IP address to the user's whitelist - through the api - while the user is logged in (during the registration process). This way I do not have to rely on the user.

I see this as a necessary solution that accords with my belief that I need to make it as simple and painless as possible for the user to start using my app. Any impediment has the probability of reducing my success rate.

Perhaps there are other ways to address this problem. I would be interested to hear them.


Colin Goldberg
David GorslineDavid Gorsline
I'm not often given to "me, too" posts, but I want to amplify the message that the rollout of the Identity Confirmation has been less than smooth for us and our customers.

My app is also a composite, with web tabs and background jobs.

A few points:

(1) The deployment date for Identity Confirmation was moved forward multiple times, and was poorly communicated, so it wasn't really possible for us to tell our customers when to react to the changes.

(2) The automatic whitelisting feature has worked reasonably well. But I am still finding cases of existing customers raising the LOGIN_MUST_USE_SECURITY_TOKEN error and other mysterious errors. Perhaps this is because our servers are part of a load-balanced farm, so each access will use a different IP address (taken from a limited subset of addresses within our subnet).

(3) As noted elsewhere in this thread, automatic whitelisting doesn't help new customers in the slightest.

(4) Salesforce.com monitors of these discussion boards have not been forthcoming in providing assistance to their development partners. Perhaps there has been information published by SFDC that will help developers troubleshoot problems introduced by the new security measures. I have yet to see it.
SteveBowerSteveBower

There is an Idea posted to have whitelisted IP ranges be specifiable as part of a Managed Package.

Please support it at: http://ideas.salesforce.com/article/show/99554/Package_IP_address_ranges__Whitelist_Certified_partner_apps

-Steve
colingcoling
I have just posted a comment on the Idea Exchange - I have pasted it below. This idea occurred to me as I read the initial posting, and is an alternative to my first idea of allowing IP addresses to be whitelisted via the api.

"Why use the packaging mechanism to address this issue? It just interferes with the upgrade/versioning process (and associated marketing, etc.) for an app.

I think a better idea would be for Salesforce.com to set up a central registry of 'trusted' partner IP addresses. In my opinion this is a much more flexible approach. And its independence from app versions etc. would make it easier to manage by Salesforce.com."

Colin Goldberg