Proxy URL

The OAuth flows provided by Gmail, Yahoo and are designed for a site like yours to request access to a person’s address book. In order for CloudSponge to be able to do the heavy lifting of importing and normalizing the contacts for your site, your application must hand the consent code over to CloudSponge.

You can accomplish this with a special page on your site that we refer to as Proxy URL.

The sole purpose of this page is to accept the token parameters from the contact source (Gmail, Yahoo or and proxy that to CloudSponge.

We have recently released a Javascript Proxy URL implementation that has no server-side dependencies. It consists of a static HTML page and Javascript file which implements the required behaviour.

Complete the following steps to install and test your OAuth proxy endpoint:

  1. Download the file here or review the full gist.
  2. Add solo-auth-proxy.html to the same directory on your web server. Your Proxy URL is done!
  3. Verify the Proxy URL by visiting the solo-auth-proxy.html page on your server.
    You should see some text and a link. Make a note of the URL, you will use this URL as Proxy URL when setting up your Developer Accounts and also the OAuth Credentials in CloudSponge.

Next you can set up your OAuth Credentials for each OAuth source, using the URL for solo-auth-proxy.html.

This Javascript implementation page is preferred over our older reference implementations because there are no server-side dependencies. Any site that can host a static HTML page can host the Proxy URL.

Server-side Proxy URL (deprecated)

For new integrations, please use our Javascript Proxy URL. The server-side Proxy URL reference implementations are listed below for reference only.

Your Proxy URL should be a transparent pass-through between the client and all request data should be forwarded directly upstream to Likewise, all response headers and data should be returned directly to the client. The page you create on your site to proxy requests needs to accept all GET parameters, make an HTTP connection to, passing the parameters with the request. When the response comes back from, the exact headers and body should be returned to the client. The typical gotcha is following redirects: returns a 302 response in many cases. Ensure that your system is configured to not follow redirects for the proper result.

CloudSponge may return a 302 Found and a Location in the response header. This response header should be returned to the user’s browser. Some platforms will automatically follow redirects so you must ensure that this functionality is turned off on your system.

Important Note: The Proxy URL cannot follow any redirect response from CloudSponge. It must proxy the request and include any GET parameters with the payload to CloudSponge.

We have several reference implementations of working Proxy URLs:

  1. HTML/JavascriptRecommended
  2. PHP (depends on the CloudSponge PHP library)
  3. Ruby (depends on the CloudSponge Ruby gem)
  4. ASP .Net
  5. Java Servlet
  6. Groovy & Grails
  7. Python & Django