DashPort Explorer is a desktop application built using Adobe AIR technology that lets you get more out of  your salesforce.com dashboards.  Some of the key features include:

• View. View your dashboard charts in a large format for easy viewing while projecting on a conference room screen. Access your dashboards while offline, whether in a remote conference room or on an airplane.
• Snapshot. Automatically capture historical snapshots of your dashboards. View and compare historical dashboards to see how your organization’s metrics have changed over time.
• Export. Export your dashboard charts and tables outside of salesforce.com to share with others in your organization who don’t have a salesforce license. Easily create PDF documents or Microsoft PowerPoint presentations from your salesforce.com dashboards.
• Print. Print your dashboards in a clean, professional style.

For more information and to start a free 2-week trial, please visit the DashPort Explorer page on our website.

• Learn how to get more out of your salesforce.com analytics with DashPort Studio and Explorer.
• View live product demonstrations.
• Win two tickets to the 2010 PGA US Open at Pebble Beach.  We are giving away two tickets to the final weekend (June 19th and 20th) of the 2010 US Open at Pebble Beach.  Stop by and enter for your chance to win!

We look forward to seeing you there!

There is not a lot of information available on implementing OAuth for salesforce other than the salesforce.com documentation and the OAuth spec, but after reading both I thought I could get a prototype working in a couple of hours.  I was proved wrong when it took over 10 hours due to challenges in debugging the OAuth protocol and an implementation bug on salesforce’s part (a fix is due this week). In the end I was successful and the effort resulted in the creation of a few new ideas on the IdeaExchange on how this feature could be improved.  This post captures some of the challenges I experienced and lessons learned.

Why use OAuth?

If you are using a 3rd party salesforce.com application, at some point you probably entered your salesforce.com credentials in the form of your username, password and security token into the application.  The application securely stores your credentials and uses them to authenticate to salesforce.com to get access to the salesforce.com API. There are a few problems with this method:

• A security compromise of the application could result in a 3rd party gaining full access to the user’s salesforce.com account.  There is no centralized way for the application provider or salesforce.com to prevent the stolen credentials from being used.  Each user would need to be notified and reset their password and security token.
• The application is granted the full privileges for that user determined by his profile.  There is no way to restrict access based on the type of application.  The net result is that many applications recommend the creation of a dedicated user account that has the correct permissions set in the profile.  This additional account increases the total cost of ownership of the application and complicates application setup and configuration.
• If a user changes her password, she must update every application with the new password and security token.

OAuth addresses these issues though the use of access tokens instead of using a user’s username, password, and security token.  To obtain an access token the application requests a new token and then directs the user to the salesforce.com website to authorize the token.  After logging in, the user is shown the following screen:

In this example, “gsOauthTest” is the name of my test application (Note the question mark icon is present because I did not provide an image url for the application).  If the user clicks Approve they are either directed back to the application (if it is a web application), or they are presented with a page that contains a verification ID to be entered in the application (in the case of desktop application).  Once the user has approved the access request, the application is then granted a valid access token.  The user can revoke access at any time.  There are several benefits to this method:

• If an application’s security is compromised and all users’ access tokens were exposed, salesforce.com could immediately revoke all access tokens that were issued to that application.
• If a user changes her password, the application’s access token is unaffected (I have verified this) and can still be used.
• In theory, an application could also be granted restricted access to salesforce.com eliminating the need for a dedicated account with special profile permissions.  However, as salesforce.com has implemented OAuth today, there is no mechanism for an application developer to specify the type of access desired.  Salesforce.com still grants the same permission as is present in the user’s profile, but I hope this is an area they can improve on in the future.

Implementing a Remote Access Application – Lessons Learned

Below are the basic steps to follow when developing an application that uses the Remote Access (OAuth) feature and some of the lessons I learned along the way:

• Create a new Remote Access Application using Setup -> Develop -> Remote Access.  This is pretty straightforward, but there are a few things worth noting.
  • The Application name is not globally unique (unlike managed package prefixes), but probably should be for security reasons.
  • You can provide an image url to be displayed on the authorization page.  If you don’t provide one, a broken image link is displayed instead, so I recommend you provide one.  Ideally salesforce.com would host the image on your behalf.
  • If you create the Remote Access Application as part of a managed package, users will not be able to authenticate using OAuth unless the package is already installed in their org.  This is an important consideration when designing your application.  For example, once a user is authenticated you can then use the API to determine if your package is installed, and if not guide the user through the process of installing it, this option is not available if you include the Remote Access Application in your managed package.  I have added an idea on how salesforce could improve the process for managed packages.
• Find a suitable OAuth client library (or write your own).  I would highly recommend using an existing OAuth library, because OAuth can be difficult to implement correctly. In my case, our application is written in ActionScript, and I was not able to find a reliable library, so I wrote my own implementation.  The protocol is not complex and can be implemented quickly, but debugging it with a working server can be difficult.  If you are implementing your own I would highly recommend implementing it with a test server first.  You can get a list here.  I used the server at http://term.ie/oauth/example/ because it gave the best error messages and allowed me to quickly debug my implementation.
• Test against the salesforce.com OAuth servers.  If you have a working client library, this should be pretty straightforward.  But I’ll offer a few tips that worked for me:
  • There are three ways to send OAuth parameters to a server:  the HTTP Authorization header, HTTP POST parameters, or HTTP GET query string.  I was only able to get OAuth to work using the HTTP POST parameters.  My attempts at using the HTTP Authorization header were not successful and I didn’t try using the GET query string.  Your mileage may vary, but I know the POST parameters work in the Winter ‘10 release.
  • Salesforce initially has an implementation bug in how they computed the OAuth signature base string when using the login URL to obtain a session id.  You can read the details here, but they have quickly fixed the issue after it was identified and will be rolling it into production this week.
  • When directing the user to the authorization page, salesforce does not automatically re-authenticate the user if they are already logged in.  Instead the user is presented with the authorization approval page immediately.  Since the authorization page does not indicate the currently logged in username, you can accidentally authorize the wrong account if you frequently use multiple accounts as I do.  I recommend logging out of your salesforce.com account before running OAuth tests to avoid any confusion during testing.
• Other implementation consideratons.
  • You should protect the access token and secret as if they were the user’s username and password.  This means storing them in an encrypted manner.  In our case Adobe AIR provides a cross-platform API to store encrypted data that uses OS-specific methods to protect data (DPAPI on Windows and KeyChain on Mac OS).
  • Access token expiration.  Salesforce.com has not specified if access tokens expire after some period of time.  For now, I’m assuming that an access token expiration looks just like a user has revoked access.  So the same code path that handles revocation should handle token expiration.
  • Unique user keys.  If your application uses the username as a unique user key to access your application’s data, you may need to make a change.  When a user authenticates with OAuth you will not be given the user’s username.  You can request it via the API using the getUserInfo method, but if the user does not have API access and your application does not require the API you may not have access to the username when using OAuth.
  • Using OAuth exclusively.  Should use OAuth as the only method for authenticating users?  Given that the implementation is so new and has a few rough edges I wouldn’t recommend it as the only method.  For our new application, we will be supporting OAuth and the old way of username/password/security token.  I haven’t yet decided which will be the default preferred way, but I am leaning towards OAuth because it is a better model in the long term and I think salesforce will quickly work out any kinks by the next release.

Summary

The Remote Access Application feature provides a number of improvements over the existing methods of authenticating and managing user credentials for 3rd party salesforce.com applications.  However, I definitely felt like an early adopter on the bleeding edge when implementing the feature in our application with the Winter ‘10 release.  I was glad to see that salesforce quickly acknlowedged and fixed the one issue I found in their implementation.  I hope they are able to smooth out some of the rough edges I have identified on the IdeaExchange in future releases.  If you already have an application that is working and in production, I wouldn’t rush out and add OAuth support quite yet, I would probably wait a release or two.  But, if you are writing a new application that can take advantage of OAuth I would recommend taking a look.  Once our application is in production, I will post a followup that covers any issues and feedback we have from our users in using the Remote Access feature.

If you are considering implementing OAuth in your salesforce.com application, please take a look at some of the ideas I posted on AppExchange and promote them if you agree:

• Identify organization and username when authorizing Remote Access Requests (OAuth)
• Salesforce should host images for Remote Access Applications (OAuth)
• Make it easier to debug Remote Access Applications (OAuth)
• Improve error message for packaged Remote Access Applications (OAuth)
• Remote Access Application names should be globally unique

Feedback and comments are welcome.

We’ve been busy at RumbleWare the past few weeks working on an exciting new addition to our DashPort product line called DashPort Explorer.  DashPort Explorer provides a new way to view your salesforce.com dashboards.  Here’s a quick list of some of the key features:

• Save  your dashboards as PDF or Microsoft PowerPoint.  No more screen captures or copy and paste to build PowerPoint presentations from dashboards.
• View salesforce.com dashboards in a larger format suitable for projecting on a large conference room screen.  No more tiny charts on the big screen.
• View historical dashboards with our snapshot feature.  No more wondering what that dashboard looked like last week or last month.

We made a quick sneak peek video to show you some of these features you can check it out at the bottom of this post.

DashPort Explorer will be available in November 2009 for Microsoft Windows, Mac OS X, and Linux.

A short video demonstration is included below.  To get more information, please visit rumbleware.com/dashport/studio/