Superpatternshttp://blog.superpat.com
Pat Patterson on the Cloud, Identity and Single Malt ScotchFri, 02 Feb 2018 18:19:14 +0000en-UShourly1https://wordpress.org/?v=4.9.3Salesforce Mutual Authentication – Part 3: Java HTTP Clientshttp://feedproxy.google.com/~r/superpat/~3/1HLCr6AMvqk/
http://blog.superpat.com/2018/02/02/salesforce-mutual-authentication-part-3-java-http-clients/#respondFri, 02 Feb 2018 18:15:15 +0000http://blog.superpat.com/?p=1665In 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:

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();
sslContextFactory.setKeyStore(ks);
// Need to set password in the SSLContextFactory even though it's set in the KeyStore
sslContextFactory.setKeyStorePassword(KEYSTORE_PASSWORD);

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

Conclusion

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!

StreamSets Data Collector's Salesforce integration accesses the SOAP and Bulk APIs via WSC, so, when I was implementing Mutual Authentication in SDC, I examined WSC to see where I could configure the client key and certificate chain. Although there is no mention of SSLContext or SSLSocketFactory in the WSC code, it is possible to set a custom TransportFactory on the WSC ConnectorConfig object. The TransportFactory is used to create a Transport, which in turn is responsible for making the HTTPS connection to Salesforce.

To enable Mutual Authentication I would need to create an SSLContext with the client key and certificate chain. This is straightforward enough:

Given the SSLContext, we can create an SSLSocketFactory and set it on the HttpsURLConnection. Here's the code we'd use if we were simply using the java.net classes directly:

URL url = new URL(someURL);
HttpURLConnection conn = (HttpURLConnection)url.openConnection();
// Check that we did get an HttpsURLConnection before casting to it
if (conn instanceof HttpsURLConnection) {
((HttpsURLConnection)conn).setSSLSocketFactory(
sslContext.getSocketFactory()
);
}

Mutual Authentication and the Salesforce SOAP API

The default Transport implementation, JdkHttpTransport, looked like a good place to start. My first thought was to extend JdkHttpTransport, overriding the relevant methods. Unfortunately, JdkHttpTransport's createConnection method, which calls url.openConnection(), is static, so it's impossible to override. The connectRaw() method also looked like a promising route, since it calls createConnection(), performs some setup on the HttpURLConnection, and then gets the OutputStream, but it's private, and once the OutputStream has been created, it's too late to set the SSLSocketFactory.

You'll generally need to set the TransportFactory in the ConnectorConfig object that you use to create the PartnerConnection (or EnterpriseConnection, etc), though another option is to set the Transport.

It's possible to create a Transport implementation that is based off of the com.sforce.ws.transport.JdkHttpTransport class while having the JdkHttpTransport create the connection with its static createConnection method. Your Transport implementation can then set up the SSLSocketFactory (casting the connection to HttpsURLConnection is required to do that), and your SSLSocketFactory can be created from creating an SSLContext that is initialized to include your client certificate.

I followed Steven's advice and created ClientSSLTransport, a clone of JdkHttpTransport, and ClientSSLTransportFactory, its factory class. To minimize the amount of copied code, I changed the implementation of connectRaw() to call JdkHttpTransport.createConnection() and then set the SSLSocketFactory:

With this in place, I wrote a simple test application to call an API with Mutual Authentication. As I mentioned in the previous blog post, the Salesforce login service does not support Mutual Authentication, so the inital code to authenticate is just the same as the default case:

Mutual Authentication and the Salesforce Bulk API

Now, what about the Bulk API? Running a test app resulted in an error when I tried to create a Bulk API Job. Tracing through the WSC code revealed that when ConnectorConfig.createTransport() creates a Transport with a custom TransportFactory, it does not set the ConnectorConfig on the Transport:

ConnectorConfig.createTransport() is only used when the WSC Bulk API client is POSTing to the Bulk API, since the POST method is hardcoded into JdkHttpTransport.connectRaw() (all SOAP requests use HTTP POST). When the client wants to do a GET, it uses BulkConnection.doHttpGet(), which does not use ConnectorConfig.createTransport(), instead calling config.createConnection():

Luckily, config.createConnection() is public, so my solution to these problems was to subclass ConnectorConfig as MutualAuthConnectorConfig, providing an SSLContext in its constructor, and overriding createConnection():

If you look at ClientSSLTransport and ClientSSLTransportFactory, you'll notice that the factory has a two-argument constructor that allows us to pass the ConnectorConfig. This ensures that the Transport can get the configuration it needs, despite the fact that ConnectorConfig.createTransport() neglects to set the config.

Now, when creating a BulkConnection from a Partner API ConnectorConfig, I use my subclassed ConnectorConfig class AND set the TransportFactory on it, so that the SSLSocketFactory is set for both GET and POST:

Proposed WSC Changes

With the above changes I was able to call both the SOAP and Bulk APIs and include the WSC JAR files unchanged. I filed issue #213 on WSC, and then fixed the problems in the WSC directly (pull request) by adding an SSLContext member variable and its getter/setter to ConnectorConfig and having JdkHttpTransport.connectRaw() and BulkConnection.doHttpGet() set the SSLSocketFactory on the HttpsURLConnection immediately after it's created. I'll update this blog entry if and when my pull request is accepted.

]]>http://blog.superpat.com/2018/01/29/salesforce-mutual-authentication-part-2-web-service-connector-wsc/feed/0http://blog.superpat.com/2018/01/29/salesforce-mutual-authentication-part-2-web-service-connector-wsc/Salesforce Mutual Authentication – Part 1: the Basicshttp://feedproxy.google.com/~r/superpat/~3/IB-2UeFCfmY/
http://blog.superpat.com/2018/01/25/salesforce-mutual-authentication-part-1-the-basics/#respondFri, 26 Jan 2018 05:42:17 +0000http://blog.superpat.com/?p=1637Mutual Authentication was introduced by Salesforce in the Winter '14 release. As the Salesforce Winter '14 release notes explain, mutually authenticated transport layer security (TLS)allows secure server-to-server connections initiated by a client using client certificate authentication, and means that both the client and the server authenticate and verify that they are who they say they are. In this blog post, I'll show you how to enable Mutual Authentication and perform some basic tests using the curl command line tool. In a future blog post, I'll show you how to implement Mutual Authentication in your Java apps.

In the default case, without Mutual Authentication, when an API client connects to Salesforce via TLS, the client authenticates the server via its TLS certificate, but the TLS connection itself gives the server no information on the client's identity. After the TLS session is established, the client sends a login request containing its credentials over the secure channel, the Salesforce login service responding with a session ID. The client then sends this session ID with each API request.

Mutual Authentication provides an additional layer of security. Each time you connect to a Salesforce API, the server checks that the client's certificate is valid for the client's org, as well as checking the validity of the session ID. Note that Mutual Authentication is intended for API use and not for user interface (web browser) use.

Before you can use Mutual Authentication, you need to obtain a client certificate. This certificate must be issued by a certificate authority with its root certificate in the Salesforce Outbound Messaging SSL CA Certificates list; Mutual Authentication will not work with a self-signed client certificate. More information is available in the Salesforce document, Set Up a Mutual Authentication Certificate. I bought an SSL certificate from GoDaddy - you can almost certainly find a cheaper alternative if you spend some time looking.

Enabling Mutual Authentication in Salesforce

Mutual Authentication is not enabled by default. You must open a support case with Salesforce to enable it. When it is enabled, you will see a Mutual Authentication Certificates section at Setup | Administer | Security Controls | Certificate and Key Management.

You must upload a PEM-encoded client certificate to this list. Note that you need only upload the client certificate itself; do not upload a certificate chain.

You will also need to create a user profile with the Enforce SSL/TLS Mutual Authentication user permission enabled. Clone an existing Salesforce profile and enable Enforce SSL/TLS Mutual Authentication. Check that the profile has the Salesforce object permissions that your application will need to access data. Assign the new profile to the user which your app will use to access Salesforce.

Testing Mutual Authentication with curl

This was a stumbling block for me for some time. First, despite what the Salesforce documentation (Configure Your API Client to Use Mutual Authentication) says, the Salesforce login service does not support Mutual Authentication. You cannot connect to login.salesforce.com on port 8443 as described in the docs.

You can, however, send a normal authentication request for a user with Enforce SSL/TLS Mutual Authentication enabled to the default TLS port, 443. The login service responds with a session ID as for any other login request. Mutual Authentication is enforced when you use the session ID with an API endpoint.

Let's try this out. Here's a SOAP login request - add a username/password and save it to login.xml:

Now you know how to get the basics of Salesforce Mutual Authentication working. In part 2 of this series, I look at using Salesforce's Web Service Connector (WSC) to access the SOAP and Bulk APIs with Mutual Authentication, and in part 3, I explain how to access the Salesforce REST APIs with common Java HTTP clients such as the Apache and Jetty.

]]>http://blog.superpat.com/2018/01/25/salesforce-mutual-authentication-part-1-the-basics/feed/0http://blog.superpat.com/2018/01/25/salesforce-mutual-authentication-part-1-the-basics/Uploading data to the Salesforce Wave Analytics Cloudhttp://feedproxy.google.com/~r/superpat/~3/Tyk7KXjmFls/
http://blog.superpat.com/2016/03/17/uploading-data-to-the-salesforce-wave-analytics-cloud/#commentsFri, 18 Mar 2016 04:18:27 +0000http://blog.superpat.com/?p=1610As you might know from my last post, I moved from Salesforce to StreamSets a couple of weeks ago. It didn't take long before I was signing up for a fresh Developer Edition org, though! I'm creating a StreamSets destination to allow me to write data to Wave Analytics datasets, and it's fair to say that the documentation is... sparse. Working from the Wave Analytics External Data API Developer Guide and Wave Analytics External Data Format Reference (why are these separate docs???), and my understanding of how Salesforce works, I was able to put together a working sample Java app that creates a dataset from CSV data.

Here's the code - I explain a few idiosyncrasies below, and reveal the easiest way to get this working with Wave.

Lines 7-14 - I'm using the WSC with the SOAP Partner API, just because I'm working in Java, and that was what was used in the bits of sample code included in the docs.

Lines 19-72 - this is the metadata that describes the CSV you're uploading. This is optional, but recommended.

Lines 75-78 - CSV is the only format currently supported, though the docs reserve a binary format for Salesforce use.

Line 82 - the dataset name must be unique across your org.

Lines 85-86 - change these to your login credentials.

Line 117 - the API wants base64-encoded data, so you'd likely try encoding the data yourself and passing the resulting string here, resulting in an error message. Instead you have to pass the raw bytes of the unencoded string and let the WSC library sort it out.

Lines 137-154 - you can repeat this block in a loop as many times as necessary.

You will need the WSC jar, and the SOAP Partner API jar - follow Jeff Douglas' excellent article Introduction to the Force.com Web Services Connector for details on setting this up - use the 'uber' JAR as it contains all the required dependencies. The sample above used Jeff's Partner API sample as a starting point - thanks, Jeff!

If you go look in the Wave Analytics app, you should see the 'tester' dataset:

Click on 'tester' and you'll see the 'big blue line':

Now you can drill into the data (all 2 rows of it!) by account name, close date etc.

You could, of course, extend the above code to accept a CSV filename and dataset name on the command line, and create all sorts of interesting extensions. Follow the StreamSets blog to learn where I plan to go with this!

]]>http://blog.superpat.com/2016/03/17/uploading-data-to-the-salesforce-wave-analytics-cloud/feed/9http://blog.superpat.com/2016/03/17/uploading-data-to-the-salesforce-wave-analytics-cloud/Thank You For The Musichttp://feedproxy.google.com/~r/superpat/~3/qCzcU_GMTRA/
http://blog.superpat.com/2016/03/04/thank-you-for-the-music/#commentsFri, 04 Mar 2016 13:45:52 +0000http://blog.superpat.com/?p=1599I joined the developer evangelism team at Salesforce in October 2010, nearly five and a half years ago. It's been a fantastic run, but it's time for me to move on, and today will be my last day with Salesforce.

So, what next? Starting on Monday I'll be 'Community Champion' at StreamSets, a San Francisco-based startup focused on open source big data ingest. I'll be blogging at their Continuous Ingest Blog, speaking at conferences (including GlueCon, coming up in May), tweeting, and learning all about this 'big data' thing I keep hearing about.

Thank you, Salesforce, for my #dreamjob, and all the fun times over the years. It's been a blast!

]]>http://blog.superpat.com/2016/03/04/thank-you-for-the-music/feed/14http://blog.superpat.com/2016/03/04/thank-you-for-the-music/Visualforce on Chromecast, as a Service!http://feedproxy.google.com/~r/superpat/~3/bZRA_PT2L9s/
http://blog.superpat.com/2014/03/25/visualforce-on-chromecast-as-a-service/#commentsTue, 25 Mar 2014 23:54:31 +0000http://blog.superpat.com/?p=1534After 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.

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.

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.

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:

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!

]]>http://blog.superpat.com/2014/03/25/visualforce-on-chromecast-as-a-service/feed/7http://blog.superpat.com/2014/03/25/visualforce-on-chromecast-as-a-service/Display ANY Visualforce Page on Google Chromecasthttp://feedproxy.google.com/~r/superpat/~3/1mDmxJQy7G0/
http://blog.superpat.com/2014/03/21/display-any-visualforce-page-on-google-chromecast/#commentsFri, 21 Mar 2014 22:22:47 +0000http://blog.superpat.com/?p=1516Last time, I described how I ran a simple 'Hello World' application, served from a Force.com 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 Force.com 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 Force.com. 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:

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.

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 Force.com 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.

]]>http://blog.superpat.com/2014/03/21/display-any-visualforce-page-on-google-chromecast/feed/5http://blog.superpat.com/2014/03/21/display-any-visualforce-page-on-google-chromecast/Getting Started with Chromecast on Visualforcehttp://feedproxy.google.com/~r/superpat/~3/pla2wAqGZPM/
http://blog.superpat.com/2014/03/07/getting-started-with-chromecast-on-visualforce/#commentsFri, 07 Mar 2014 19:03:49 +0000http://blog.superpat.com/?p=1493About a month ago, Google released the Google Cast SDK, allowing developers to create apps that run on the Chromecast, a $35 digital media player. The primary use case of Chromecast is to stream media - movies, TV shows, music and the like - via wifi to your HDMI TV/monitor, but, looking at the SDK docs, it became apparent that the Chromecast is actually a miniature ('system-on-chip') computer running Chrome OS (a Linux variant) and the Chrome browser. If it's running a browser, I wondered, could it load Visualforce pages from Salesforce and display, for example, a chart based on live data? If so, this would allow any HDMI-capable TV or monitor to be used as a dashboard at very low cost. When I was given a Chromecast by a colleague (thanks, Sandeep!) in return for alpha testing his app, I decided to find out!

This first blog post explains how I ran a simple 'Hello World' sample on the Chromecast, loading the app from Visualforce. Next time, I'll show you how I pulled data from Salesforce via the REST API and showed it as a chart.

Chromecast setup was pretty straightforward - a matter of connecting the device to an HDMI input on my TV and a USB power source, downloading and running the Chromecast app, and following the prompts to complete setup. The Chromecast app locates the device on the local network using the DIAL protocol. Note that, since the app is communicating directly with the device, it won't work on wifi networks that enforce AP/Client Isolation (many offices and hotels).

After installing the Cast Extension for Chrome and verifying that the Chromecast could display content from YouTube, it was time to put the device into development mode! This actually proved to be pretty tricky - you need to enter the Chromecast's serial number into the Google Cast SDK Developer Console. Sounds straightforward, but the serial number is laser etched into the Chromecast's black plastic case in very small type indeed. I entered it incorrectly the first time round, and had to take a photo of the serial number and zoom in to see that the last character was an S and not an 8!

Another gotcha I encountered is that it's necessary to go into the Chromecast settings (in the Chromecast app) and enable Send this Chromecast's serial number when checking for updates. This information is on a separate page from the device registration instructions, so it's easy to miss.

Now my Chromecast showed up in the developer console, it was time to get an app running. Since the Chromecast has no input devices (keyboard, mouse, etc), a 'receiver app' running in an HTML5 page on the device is controlled by a 'sender app' running on a 'second screen' such as a laptop, smartphone or tablet. The two apps are connected over the local network by a message bus exposed by the Google Cast SDK.

Looking through the samples, CastHelloText-chrome looked like the simplest example of a custom receiver. In the sample, the sender app, running on an HTML5 page in Chrome, allows you to enter a message ('Hello World' is traditional!) and sends it on the bus. The receiver app displays the message, and reflects it back to the sender, to demonstrate the bidrectional nature of the bus.

It was straightforward to convert the vanilla HTML pages to Visualforce - the first change was to wrap the entire page in an tag and remove the DOCTYPE, since Visualforce will supply this when it renders the page.

Adding the Visualforce pages to a Force.com Site made them public on the web. This is important - the Chromecast can only load public web pages - it has no way of authenticating to a server. You'll find out in the next blog post how I was able to access the Force.com REST API to securely retrieve content.

Once I had a pair of public pages, I registered my sample app, entering the public URLs for my Visualforce pages, and pasted the resulting app ID into the chromehellotext page. Loading that page gave me a text control into which I could type a message. Hitting return to submit the message pops up the Cast device selector.

I selected my device from the list, and - 'BAM!' - my message popped up on the TV screen - success!

One very nice feature of the Chromecast is that it allows remote debugging in Chrome. You can find the device's IP address in the Chromecast app, say 192.168.1.123, and simply go to port 9222 at that address, in my example, http://192.168.1.123:9222/.

You get the usual Chrome developer tools, right down to the ability to set breakpoints and inspect variables in JavaScript - marvelous!

I've published the sample app, so you can try it out yourself. If you have a Chromecast, go to my sender app page; you should be able to connect to your device and send a message.

At this point, I had to do some thinking. The Chromecast, as I mentioned before, loads a page from a public web server. How could I show data on the page, preferably without making the data itself publicly available? Read on to the next post!

]]>http://blog.superpat.com/2014/03/07/getting-started-with-chromecast-on-visualforce/feed/2http://blog.superpat.com/2014/03/07/getting-started-with-chromecast-on-visualforce/Raspberry Pi fix for HDMI to DVI cable issuehttp://feedproxy.google.com/~r/superpat/~3/ypXNXxEditk/
http://blog.superpat.com/2012/06/08/raspberry-pi-fix-for-hdmi-to-dvi-cable-issue/#commentsFri, 08 Jun 2012 18:10:01 +0000http://blog.superpat.com/?p=1389My 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.

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!

]]>http://blog.superpat.com/2012/06/08/raspberry-pi-fix-for-hdmi-to-dvi-cable-issue/feed/29http://blog.superpat.com/2012/06/08/raspberry-pi-fix-for-hdmi-to-dvi-cable-issue/Running Your Own Node.js Version on Herokuhttp://feedproxy.google.com/~r/superpat/~3/eG7sWtfV1vU/
http://blog.superpat.com/2011/11/15/running-your-own-node-js-version-on-heroku/#commentsWed, 16 Nov 2011 06:02:45 +0000http://blog.superpat.com/?p=1370UPDATE (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:

First, you'll need to fork https://github.com/heroku/heroku-buildpack-nodejs. 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: