By Bryan Leboff (@leboff)
Recently I was finding myself doing a lot testing in a Salesforce sandbox as a bunch of different users, with different profiles. Logging in and out as different users and clicking through the setup menu was becoming a real time suck so I set out to find a better solution. As I searched through the Chrome store for an extension to alleviate my woes I found this wonderful tool Salesforce.com Quick Login As. The only problem was my org had a massive number of users and I was not able to quickly search through the lists to find the one I wanted. So I set out to write my own tool to allow me to do this.
I decided to use the ForceTk toolkit (is that redundant?) to query for the users from the Salesforce org, which means that I would have to require the user to be authenticated, but keeping track of sessions and OAuth authorizations or usernames and passwords seemed unnecessary and complicated. Instead, realizing that Salesforce stores the current user’s session id in a cookie and ForceTk allows you to set the session id on an ad hoc basis, I figured I could ‘borrow’ this session id for making my call to SFDC to grab the list of users.
The chrome extension can have a persistent page called the background page. This page in my extension checks if the URL is *.salesforce.com or *.force.com and loads a new ForceTk client. I was able to use the chrome cookies api (which requires the “cookies” permission in your manifest.json file) to acquire the ‘sid’ cookie.
After setting ForceTk session id to the value in the cookie, it allowed me to make any query available to the current logged in user, without forcing them to log in to another app! Before each query we check that the organization ID stored in the ‘oid’ cookie hasn’t changed, and make the call. If it has changed we need to reacquire the session id cookie and set the value in the ForceTk client again.
You can see this all go down at line 55 of my background.js file. Using this method of session borrowing allows us to create all sorts of extra functionality around Salesforce.com administration and usage without requiring the extra steps and overhead of having the end user log in.
Obviously taking this approach may raise some security concerns for users. One way to mitigate these is through locking down sessions to their originating IP, which Salesforce provides as a setting under Administer -> Security Controls -> Session Settings -> Session Settings -> Lock sessions to the IP address from which they originated.
Also if you’re interested in the extension, you can grab it here: Loginas Beta