This blog is in continuation of my previous blog “Sitecore-Salesforce Integration- Steps, Issues, Troubleshooting” which can be referred at http://sitecorestudy.com/?p=107 .
So, here I would like to share the showstopper that I had encountered during the Sitecore-Salesforce integration through Salesforce Connect Module , detailed analysis and the ways to overcome that. Although, I found this issue around a year ago and had shared this with Sitecore too, I didn’t get a chance to share it online, but better late than never
Before starting, I highly appreciate that we have such modules readily available to be integrated with Sitecore application and I also thank the contributors for the same.
ISSUE DESCRIPTION: “Authentication Failure”
I had been provided a Salesforce account with all the required permissions to start integrating Salesforce and Sitecore. And as a good practice, the Salesforce account provided was a replica of the production site of the client and not the production site. I completed the installation and configuration on Sitecore as well as Salesforce part. But somehow, it was in “Red”. It didn’t really work out. It said “Authentication failure” in the logs as can be seen below:
However, the strange part was that I could login Salesforce using the same credentials which I was supplying through the config files. But still the occurrence of the error “authentication failure” hit my head. So, I thought it might be some sort of accessibility issue/network firewall issue which is stopping it to work. So, I took it to one of the most senior Salesforce guy who actually tried out various options to make it work. But hard luck. I took it to network guys, but all in vain.
Then I created a developers account on Salesforce and did the configurations again for this new account. Bingo!!! It worked.
So, now the challenge was to find out the difference between the client’s Salesforce account and the developers account which I created. So, created a check list as below:
- Configuration difference.
- Accessibility rule setup difference.
- Allowed IP range difference (Network Accessibility)
The first three rules ruled out. Now the only leftover difference I could see was that the developers account is a sort of live account (login.salesforce.com), however the client’s Salesforce account was a Sandbox (test.salesforce.com) account which is usually created for testing purposes and why not? We too have development environments, then QA, Staging, CM CD (Production). Even we never take anything directly to the production. So similarly they have Sandboxes which is used prior taking anything to the production.
So, now I was left over with decompiling this module. I installed .net reflector and while decompiling and then debugging I found that every time the login credentials are passed to a fixed URL which is “login.salesforce.com”, and that is the reason it fails for Sandboxes for which the login URL is “test.salesforce.com”. And that is why we get the “authentication failure” message. So, basically I found it is hardcoded as shown in the below screen shots:
- So not to use the Salesforce Sandbox, which is although the easiest option but not recommended as I somewhere read that “A sandbox is a very important tool in Salesforce for testing and development without affecting your live instance.”
- This module basically reads the information such as Consumer key, consumer secret, username, password, security token from the “Clients” section of the config file. Even the <tokenRequestUri> is configurable, which can be added to “Clients section”. This should be referring to a proper Sandbox URI and then you should be getting the value of it from the configuration file.
I feel happy to share my experience and findings, which might help a few. Cheers