Update: December 17th 2008
Salesforce released an update today which resolves this issue. You can read the response to my original post about it here
Below is a test you can perform that checks whether salesforce.com have addressed the issue I allude to in this post.
The issue is in connecting to salesforce.com when your app is hosted outside their server farm and specifically from a Flex application.
The way this is done is by providing a URL to your Web Services client which points to the gateway which serves the web API at salesforce.com. To get at your specific data you have to log in through that gateway providing your salesforce.com username, password and security token. Oh, and this only works if you have an Enterprise or Unlimited salesforce.com license, otherwise access to your data through the API is not supported.
What’s a Security Token?
The security token is a 25 character string which is uniquely generated for you and assigned to your user. It is used as an additional piece of verification of your identity when you connect to salesforce.com through its API. Here is what one looks like…
To get a security token you log in to your salesforce.com account and go to the setup page. There you’ll see a section called “My Personal Information” with a link to “Reset your security token”. Click that link and you’ll get an email from salesforce.com sent to your nominated account with the security token embedded in it.
When you are presented with a login screen from an application which uses the API (i.e. any AppExchange application) you have to tack this magic text onto the end of your password otherwise you’ll be rejected with an invalid logon message.
For this test you’ll need to know your designated server too. This is easy to find. If you have just logged in to salesforce.com to get your token then look at your browser address bar and you should see a URL like this…
the bit that represents your server is the bit that say na5 above.
The test involves going to the furryhappymonsters site below and trying out a couple of URL’s and seeing what happens.
The URL defines the server that delivers the API for your particular data. You shouldn’t have to know which server you are attached to, it should just be possible to use www, e.g…
(BTW, the 11.0 at the end targets the version of the API that you want to use. salesforce.com are up to 14.0 at time of writing, but you can try out numbers above 8.0 for this test).
The bug is that if you go in via www you will get bounced with a message that implies that you have your login credentials wrong. You can check the message in the “Debug Events” box bottom right on the site. presuming you supply the correct credentials, including the security token tacked on the end of your password, then this should work.
If you change the URL so that your designated server is the target, e.g. for me…
then you’ll be let in and can query for data.
If the www route works, then they have fixed the bug.
The furryhappymonsters site belongs to James Ward from Adobe and I should thank him and my salesforce.com contacts for helping me out tracking down this issue and providing the bridge code as well.
If you are likely to follow my footsteps down the path of integration between FLex and salesforce.com then details of the excellent bridge code provided by James can be found here.