Salesforce Mutual Authentication – Part 3: Java HTTP Clients

HTTP Client LogosIn part 1 of this short series of blog entries on Salesforce’s Mutual Authentication feature, I explained how to enable, configure and test Mutual Authentication. In part 2, I documented the shortcomings of Salesforce’s Web Service Connector when trying to use Mutual Authentication, and showed how to work around them. This time, I’m going to show you how to use common Java HTTP Clients to call Salesforce APIs with Mutual Authentication.

Recall from part 1 that enabling Mutual Authentiation on a Salesforce Profile means that users with that profile must call a separate API endpoint, connecting via TLS with a client key and certificate chain. A Java client application can load the client key and certificate as I explained in part 2:

// Make a KeyStore from the PKCS-12 file
KeyStore ks = KeyStore.getInstance("PKCS12");
try (FileInputStream fis = new FileInputStream(KEYSTORE_PATH)) {
  ks.load(fis, KEYSTORE_PASSWORD.toCharArray());

// Make a KeyManagerFactory from the KeyStore
KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
kmf.init(ks, KEYSTORE_PASSWORD.toCharArray());

// Now make an SSL Context with our Key Manager and the default Trust Manager
SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(kmf.getKeyManagers(), null, null);

We’ll also need to obtain a session ID. I’ll just reuse the SOAP login code from last time, though you could also use any of the OAuth mechanisms.

// Login as normal to get instance URL and session token
ConnectorConfig config = new ConnectorConfig();

// Uncomment for more detail on what's going on!

// This will set the session info in config

// Display some current settings
System.out.println("Auth EndPoint: "+config.getAuthEndpoint());
System.out.println("Service EndPoint: "+config.getServiceEndpoint());

String sessionId = config.getSessionId();
String instance = new URL(config.getServiceEndpoint()).getHost();

Let’s look at how we proceed then, in a few common scenarios. All of the below code is available in this Github project.

Java’s HttpURLConnection

This is pretty much the most basic way of accessing an HTTP endpoint in Java. We create a URL object and get the HttpURLConnection as usual, then we can set the SSLSocketFactory on the connection:

// URL to get a list of REST services
// For example:
URL url = new URL("https://" + instance + ":" + MUTUAL_AUTHENTICATION_PORT
    + "/services/data/v" + API_VERSION);

HttpURLConnection conn = (HttpURLConnection)url.openConnection();

// Check that we did get an HttpsURLConnection before casting to it
if (conn instanceof HttpsURLConnection) {

Now we set the authorization header as we normally would. I’m also using the X-PrettyPrint header to make the REST API response a bit easier to read.

// Set the Authorization header
conn.setRequestProperty("Authorization", "OAuth "+sessionId);
// Make the response pretty
conn.setRequestProperty("X-PrettyPrint", "1");

Finally, we’ll pull the data from the HttpURLConnection’s OutputStream and dump it to System.out:

// Dump the response to System.out
try (BufferedReader br =
    new BufferedReader(
      new InputStreamReader(conn.getInputStream()))) {
  String input;

  while ((input = br.readLine()) != null){

The result is the expected list of Salesforce REST services:

  "tooling" : "/services/data/v41.0/tooling",
  "metadata" : "/services/data/v41.0/metadata",
  ...lots more...
  "sobjects" : "/services/data/v41.0/sobjects",
  "actions" : "/services/data/v41.0/actions",
  "support" : "/services/data/v41.0/support"

Apache HttpClient

How does the same example look with Apache HttpClient? We just need to set the SSLContext in the Apache CloseableHttpClient:

// URL to get a list of REST services
String url = "https://" + instance + ":" + MUTUAL_AUTHENTICATION_PORT
    + "/services/data/v" + API_VERSION;

// Set the SSLContext in the HttpClient
try (CloseableHttpClient httpclient = HttpClients.custom()
    .build()) {
  HttpGet httpGet = new HttpGet(url);
  // Set the Authorization header
  httpGet.addHeader("Authorization", "OAuth "+sessionId);
  // Make the response pretty
  httpGet.addHeader("X-PrettyPrint", "1");

  // Execute the request
  try (CloseableHttpResponse response = httpclient.execute(httpGet);
       BufferedReader br =
         new BufferedReader(
           new InputStreamReader(response.getEntity().getContent()))
    // Dump the response to System.out
    String input;
    while ((input = br.readLine()) != null){

The output is identical to the previous example.

Eclipse Jetty

Jetty is a little more complex. We need to create a Jetty SslContextFactory, rather than a standard Java KeyManagerFactory and SSLContext. Note that we need to set the KeyStore password in the SslContextFactory:

SslContextFactory sslContextFactory = new SslContextFactory();
// Need to set password in the SSLContextFactory even though it's set in the KeyStore

Now we can create a Jetty HttpClient with the SslContextFactory, and start it:

HttpClient httpClient = new HttpClient(sslContextFactory);

Executing the request proceeds as usual, and results in identical output:

String response = httpClient.newRequest(url)
    .header("Authorization", "OAuth " + sessionId)
    .header("X-PrettyPrint", "1")


Don’t forget to stop the HttpClient when you’re done with it:



Salesforce Mutual Authentication offers an additional layer of security over default server-authenticated TLS – clients must possess the key corresponding to a certificate configured in the Salesforce org. As I showed in part 1 of this series of blog entries, configuring Mutual Authentication in Salesforce is straightforward, as is testing the connection with curl, although the Salesforce documentation is not totally accurate. Salesforce’s Web Service Connector requires some modifications to make it compatible with Mutual Authentication, although, as I explained in part 2, it is possible to engineer around the issues. The popular Java HTTP clients all provide mechanisms for setting the client key and certificate, and using them to call the Salesforce REST APIs is straightforward. Source code showing how to use Mutual Authentication via all of the above mechanisms is available in my mutual-auth GitHub repo.

I hope you’ve enjoyed this exploration of Mutual Authentication, and that you’ve saved yourself a bit of time by reading it!

Visualforce on Chromecast, as a Service!

After writing my last blog entry, on how to display any Visualforce Page on Google Chromecast, it occured to me that I could run the app on Heroku. So, if you have a Google Chromecast, and a Salesforce login with API access enabled, you can try it out right now.

Go to; you’ll see this page:

Visualforce on Chromecast

Follow the instructions, log in, authorize the app to access your data, and you’ll be able to select a Visualforce Page to ‘cast’ to your TV.

Select a Visualforce Page

One new feature here – if you select a Visualforce Page that uses a standard controller, and is thus expecting a record ID as a parameter, you’ll get the opportunity to select a record. For simplicity, I’m just showing the first 10 records returned by the database.

Select a Record

Choose a record, hit send, and you’ll see the page displayed by the Chromecast, in this case, it’s a Mini Hack we ran a couple of Dreamforces ago:


As always, the code is on GitHub.

Having done Raspberry Pi, Minecraft, and now Chromecast, I’m looking for new ideas for interesting Salesforce integrations. Leave a comment if you think of one!

Display ANY Visualforce Page on Google Chromecast

Last time, I described how I ran a simple ‘Hello World’ application, served from a Site, on the Google Chromecast, a $35 digital media player. In this blog entry, I’ll show you how to show any Visualforce page, not just a public page on a Site, on the Chromecast.


A quick recap… (Skip this paragraph if you’ve already read the previous entry). Chromecast is actually a tiny wifi-enabled Linux computer, running the Chrome browser, connected to a TV or monitor via HDMI. A ‘receiver’ app, written in HTML5, runs on the device, which has no input capability (mouse/keyboard), while a ‘sender’ app runs on a ‘second screen’ such as a laptop, smartphone, or tablet, the two apps communicating across the local wifi network via a message bus. The sender app typically allows the user to navigate content and control the media stream shown on the Chromecast (the ‘first screen’). The CastHelloText-chrome sample allows the user to type a message in the sender app on the first screen, and displays it on the second screen via the receiver app.

Given a working sample, the next question was, how to access data from the receiver app? The core problem is that the Chromecast can only load a public web page – it can’t login to The sender app runs on a desktop browser, smartphone or tablet, however, so perhaps it would be possible to login there, and send a session ID to the receiver app via the message bus? I worked through a few alternatives before I hit on the optimal solution:

Load the Visualforce page via Frontdoor.jsp

Frontdoor.jsp, which has existed for some time, but has only been formally documented and supported since the Winter ’14 Salesforce release, “gives users access to Salesforce from a custom Web interface, such as a remote access site or other API integration, using their existing session ID and the server URL”.

To authenticate users with frontdoor.jsp, you pass the server URL and session ID to frontdoor.jsp in this format:

Sounds perfect! The only problem is that the session ID you pass to frontdoor.jsp must come from one of:

  • The access_token from an OAuth authentication (obtained with ‘web’ or ‘full’ scope)
  • The LoginResult returned from a SOAP API login() call
  • The Apex UserInfo.getSessionId()

The session ID from a Visualforce page or controller isn’t going to cut it here. So, I reached for Kevin O’Hara‘s excellent nforce and built a quick Node.js sender app that has the user authorize API access via OAuth (including web scope!), runs a query for the list of Visualforce Pages in the org and presents them as a drop-down list. You can choose a Visualforce Page, hit ‘Send’, and the sender app constructs the frontdoor URL with the OAuth access token and relative URL for the page and sends it to the receiver via the message bus.

Screen Shot 2014-03-21 at 12.09.08 PM

Note that, while you can indeed send any Visualforce page to the Chromecast for display, remember that the Chromecast doesn’t have any capacity for user input, so tables and charts work best.

I tried a couple of approaches for the receiver app; first I simply redirected to the frontdoor URL, but then I realized that it would be more useful to load the frontdoor URL into a full-page iframe. That way, the receiver app could stay running in the ‘top’ document, ready to receive a different URL, and periodically reloading the iframe so that the session doesn’t time out. Here it is in action:

All of the code is in my CastDemo project on GitHub. Feel free to fork it, extend it, and let me know in the comments how it works out.

When it came down to the code, this was a very straightforward integration; the vast majority of the work was thinking around the problem of how to have a device with no input capability authenticate and load a Visualforce page. Now that Frontdoor.jsp is documented and supported, it’s an essential tool for the advanced developer.

POSTSCRIPT: Almost as soon as I hit ‘publish’ on this post, I realized I could push the app to Heroku, and allow anyone with a Chromecast and API access to Salesforce to see their Visualforce Pages on TV. Read the next installment here.

Raspberry Pi fix for HDMI to DVI cable issue

My Raspberry Pi arrived this week. After creating a boot image on an SD card I had lying around (using the excellent RasPiWrite utility), I initially booted it up on my TV, using the composite video output – all working!

Raspberry Pi in text mode

After a little exploration from the command line, startx brought up the GUI.

Raspberry Pi running X

As well as the composite video output, the Raspberry Pi supports HDMI. My monitor (a Viewsonic VX2235WM-3) has VGA and DVI inputs, so I ordered the AmazonBasics HDMI to DVI Cable. Connecting up to my monitor, I was disappointed to see no video signal whatsover – the monitor wasn’t seeing the Raspberry Pi at all.

Googling around, I discovered that you can set various configuration options that are read before the Raspberry Pi even boots. With a little experimentation, I found that setting


in config.txt solves the problem – I see video output from the moment I power up the Raspberry Pi! This makes sense – the description of hdmi_force_hotplug is “Use HDMI mode even if no HDMI monitor is detected” – I’m guessing the cable is not signalling the presence of a monitor to the Raspberry Pi, so it decides that it doesn’t need to send HDMI output.

Watch this space for more Raspberry Pi fun!

Running Your Own Node.js Version on Heroku

UPDATE (3/3/12) – there’s a much easier way of doing this now – see ‘Specifying a version of Node.js / npm‘ in the Heroku Dev Center. The mechanism described below still works, but you should only go to all this trouble if you want something really custom.

Here’s a completely unofficial, unsupported recipe for running your own Node.js version on Heroku. These instructions are based on those at the Heroku Node.js Buildpack repository, with some extra steps that I found were necessary to make the process work. Note that buildpack support at Heroku is still evolving and the process will likely change over time. Please leave a comment if you try the instructions here and they don’t work – I’ll do my best to keep them up to date.

Before you start, update the heroku gem, so it recognizes the --buildpack option:

gem update heroku

(Thanks to ‘tester’ for leaving a comment reminding me that using an out of date heroku gem can result in the error message ! Name must start with a letter and can only contain lowercase letters, numbers, and dashes.)

Note: If you just want to try out a completely unofficial, unsupported Node.js 0.6.1 on Heroku, just create your app with my buildpack repository:

$ heroku create --stack cedar --buildpack

Otherwise, read on to learn how to create your very own buildpack…

First, you’ll need to fork Now, before you follow the instructions in the README to create a custom Node.js buildpack, you’ll have to create a build server (running on Heroku, of course!) with vulcan and make it available to the buildpack scripts. You’ll have to choose a name for your build server that’s not already in use by another Heroku app. If vulcan create responds with ‘Name is already taken‘, just pick another name.

$ gem install vulcan
$ vulcan create YOUR-BUILD-SERVER-NAME

Now you can create your buildpack. You’ll need to set up environment variables for working with S3:


Create an S3 bucket to hold your buildpack. I used the S3 console, but, if you have the command line tools installed, you can use them instead.

Next you’ll need to package Node.js and NPM for use on Heroku. I used the current latest, greatest version of Node.js, 0.6.1, and NPM, 1.0.105:

$ support/package_node 0.6.1
$ support/package_npm 1.0.105

Open bin/compile in your editor, and update the following lines:


Now commit your changes and push the file back to GitHub:

$ git commit -am "Update Node.js to 0.6.1, NPM to 1.0.105"
$ git push

You can now create a Heroku app using your custom buildpack. You’ll also need to specify the Cedar stack:

$ heroku create --stack cedar --buildpack

When you push your app to Heroku, you should see the custom buildpack in action:

$ cd ../node-example/
$ git push heroku master
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (11/11), 4.02 KiB, done.
Total 11 (delta 1), reused 0 (delta 0)

-----> Heroku receiving push
-----> Fetching custom build pack... done
-----> Node.js app detected
-----> Fetching Node.js binaries
-----> Vendoring node 0.6.1
-----> Installing dependencies with npm 1.0.105

Dependencies installed
-----> Discovering process types
Procfile declares types -> web
-----> Compiled slug size is 3.3MB
-----> Launching... done, v6 deployed to Heroku

cd3c0e2..33fdd7a  master -> master
$ curl
Hello from Node.js v0.6.1


Note: Due to an incompatibility between the default BSD tar on my Mac and GNU tar on Heroku, I saw many warnings while pushing my Node.js app to Heroku, of the form

tar: Ignoring unknown extended header keyword `'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'

These are annoying, but benign – the push completes successfully. If you’re on a Mac and you want to get rid of them, add the line

alias tar=gnutar

just after the opening #!/bin/sh in both package scripts.

Node.js Chat Demo on Heroku

STOP! If you’re just getting started with Node.js and/or Heroku, then go read James Ward’s excellent Getting Started with Node.js on The Cloud, then come back here…

Heroku‘s announcement of the public beta of their new ‘Celadon Cedar’ stack, including Node.js support, inspired me to try out Ryan Dahl‘s Node Chat demo server on Heroku. Getting it up and running was very straightforward – I went to GitHub, forked Ryan’s node_chat project to my own account and grabbed the source:

ppatterson-ltm:tmp ppatterson$ git clone git://
Cloning into node_chat...
remote: Counting objects: 183, done.
remote: Compressing objects: 100% (72/72), done.
remote: Total 183 (delta 117), reused 168 (delta 110)
Receiving objects: 100% (183/183), 50.07 KiB, done.
Resolving deltas: 100% (117/117), done.

Now I could create my Heroku app…

ppatterson-ltm:tmp ppatterson$ cd node_chat/
ppatterson-ltm:node_chat ppatterson$ heroku create --stack cedar node-chat
Creating node-chat2... done, stack is cedar |
Git remote heroku added

…and add the couple of files that Heroku needs to run a Node.js app (see the excellent Heroku docs for more info):

ppatterson-ltm:node_chat ppatterson$ echo "web: node server.js" > Procfile
ppatterson-ltm:node_chat ppatterson$ echo "{ \"name\": \"node-chat\", \"version\": \"0.0.1\" }" > package.json
ppatterson-ltm:node_chat ppatterson$ git add .
ppatterson-ltm:node_chat ppatterson$ git commit -m "Heroku-required files" Procfile package.json
[master a7617af] Heroku-required files
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 Procfile
create mode 100644 package.json

Now everything is ready to deploy:

ppatterson-ltm:node_chat ppatterson$ git push heroku master
Counting objects: 187, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (67/67), done.
Writing objects: 100% (187/187), 50.40 KiB, done.
Total 187 (delta 118), reused 182 (delta 117)

-----> Heroku receiving push
-----> Node.js app detected
-----> Vendoring node 0.4.7
-----> Installing dependencies with npm 1.0.8

Dependencies installed
-----> Discovering process types
Procfile declares types -> web
-----> Compiled slug size is 2.9MB
-----> Launching... done, v4 deployed to Heroku

* [new branch]      master -> master
ppatterson-ltm:node_chat ppatterson$ heroku ps
Process       State               Command
------------  ------------------  ------------------------------
web.1         starting for 3s     node server.js
ppatterson-ltm:node_chat ppatterson$ heroku ps
Process       State               Command
------------  ------------------  ------------------------------
web.1         up for 6s           node server.js
ppatterson-ltm:node_chat ppatterson$ heroku open

And, just like that, my chat server is up and running and I see it in my browser. It all works nicely – I can hit the URL from a couple of browsers and see all the chat messages going back and forth. Only one problem, though – I’m seeing errors when the chat server is idle:

A look at the logs reveals that connections are timing out.

2011-06-14T19:10:44+00:00 app[web.1]: <Pat2> Hi there
2011-06-14T19:10:44+00:00 heroku[router]: GET dyno=web.1 queue=0 wait=0ms service=6ms bytes=16
2011-06-14T19:10:44+00:00 heroku[router]: GET dyno=web.1 queue=0 wait=0ms service=3520ms bytes=102
2011-06-14T19:10:53+00:00 app[web.1]: <Pat> Now I can talk to myself - woo hoo!
2011-06-14T19:10:53+00:00 heroku[router]: GET dyno=web.1 queue=0 wait=0ms service=2ms bytes=16
2011-06-14T19:10:53+00:00 heroku[router]: GET dyno=web.1 queue=0 wait=0ms service=9185ms bytes=128
2011-06-14T19:10:53+00:00 heroku[router]: GET dyno=web.1 queue=0 wait=0ms service=9203ms bytes=128
2011-06-14T19:11:24+00:00 heroku[router]: Error H12 (Request timeout) -> GET dyno=web.1 queue= wait= service=30000ms bytes=
2011-06-14T19:11:24+00:00 heroku[router]: Error H12 (Request timeout) -> GET dyno=web.1 queue= wait= service=30000ms bytes=

So what’s up? The answer is in the Heroku docs for the new HTTP 1.1 stack:

The routing stack will terminate connections after 60 seconds on inactivity. If your app sends any data during this window, you will have a new 60 second window. This allows long-polling and other streaming data response.

From the logs, it looks like the connection is being dropped after only 30 seconds, but, no matter, the principle is the same – I need to periodically send some data to keep the connections open. The solution I settled on was having each client set a 20 second timer after it starts its long poll; on the timer firing the client sends a ‘ping’ message (effectively an empty message) to the server, which, in turn, forwards the ping to all attached clients, causing them to cancel their ping timers and iterate around the long polling loop. Normal chat traffic also causes the timer to be cancelled, so the pings are only sent during periods of inactivity. You can see the diffs here. Now my chat server stays up for hours without an error:

If you grab my fork from GitHub, you’ll see I also added message persistence, using Brian Carlson’s node-postgres module – mostly because I just wanted to see how easy it was to access PostgreSQL from Node.js on Heroku. The answer? Trivially easy 🙂 As Jeffrey mentions in the comments, apart from those code changes, I also needed to add the ‘pg’ module in package.json and the shared-database addon. The new package.json looks like this:

  "name": "node-chat",
  "version": "0.0.1",
  "dependencies": {
    "pg": "0.5.0"

The command to install the shared-database addon is:

heroku addons:add shared-database

Disclosure – I am a employee, so I’m definitely a little biased in favor of my Heroku cousins, but, I have to say, I remain hugely impressed by Heroku. It. Just. Works.

Superpatterns Reboot

You’ll probably have noticed that things have been pretty quiet here at Superpatterns this past few months – mainly because the blog has been the outlet for my work-related blogging. If you’ve been coming here in the past for the identity-related content, you might be interested in some of my posts there:

Some topics just don’t fit into the main ‘flow’ over at, though, so I’ll start blogging them here and flag them from from time to time. Tune in later today for some Node.js goodness…

Planet Identity Up and Running Again

A couple of folks (Hi Eve, Ash!) pinged me over the past couple of days to report problems with Planet Identity – specifically, the site was up, but hadn’t aggregated any new posts since January 9th. It looks like the machine that hosts it (courtesy of Stephen Lau – my continued thanks for his generosity!) got an OS upgrade that weekend, and my cron job was dropped in the transition. A quick kick, and all is running fine now. Thanks, Eve and Ash for the heads up, and all the best at Forrester, Eve!

WordPress Tip – Redirect to Main Page on 404

If you’re using the Postalicious WordPress plugin to post your links to your blog, you might have noticed that it doesn’t always handle the occasional 500 errors from very well, and you end up with a bogus ‘links’ entry on your blog with a link to ‘500 Server Error’.

In itself, it’s not that big a deal; I usually notice the bogus post pretty quickly and just delete it, but, by then, it’s been tweeted by Twitterfeed, pushed to Facebook, and folks have it in their RSS stream, so they hit the ‘links for the day’ link and get the default ‘404 page not found’ message. In fact, if you ever delete a post for any reason, you’re in the same situation – the link is out there, you can’t call it back (even if you go delete it from Twitter and Facebook, it’s still out there somewhere!), and people are going to land on that ugly page.

So, I got thinking… That default 404 page isn’t really good for much… What if I could just send people to the main page of my blog? Well, with a couple of minutes googling I found a useful blog post on the subject and the WordPress docs for get_bloginfo(), and came up with the following replacement for the default 404 page:

   header("Status: 301 Moved Permanently");
   header("Location: ".get_bloginfo('url'));

You could do fancier things with a JavaScript redirect that shows a ‘page not found’ message then redirects after a few seconds, but I prefer the more direct approach 🙂