Google Maps API for Business

Troubleshooting Maps API for Business Authorization

Google Maps & Earth Enterprise Support Team
December 2011

Maps API for Business client IDs are restricted to URLs specifically authorized. If you try to use your client ID at a URL that has not been authorized, you will receive an error message.

This article is intended for Maps API for Business customers who encounter this issue and need to find the exact URL that needs to be authorized.

Contents

  1. Basics
  2. The Problem
  3. The Solution
    1. How to find the correct URL
      1. From HTTP headers in your browser
      2. Finding the common pattern

Basics

In order to prevent third parties from using your client ID on their own website, the use of your client ID is restricted to a list of URLs that you need to authorize. Each URL can be as specific as a single web page or as generic as an entire domain.

To obtain a list of your authorized URLs, or to authorize additional URLs:

  1. Log in to the Google Enterprise Support Portal.
  2. From the left side menu, click Maps: Manage Client ID.

You may add up to 100 URLs at a time, to a total of 3000 URLs. If you require higher limits, please contact Google Enterprise Support.

More information about authorizing URLs is available from the Getting Started chapter of the Google Maps API for Business documentation.

The Problem

An application that lives at a URL that has not been authorized for your client ID will not be able to use the Maps API with your client ID. A user trying to use such an application will receive an error message, depending on the specific API the application tries to load.

  • The Maps JavaScript API V3 will display this message:

    Google has disabled use of the Maps API for this application. This site is not authorized to use the Google Maps client ID provided. If you are the owner of this application, you can learn more about registering URLs in the Getting Started chapter of the Maps API for Business documentation.

  • The Maps JavaScript API V2 and Maps API for Flash will display this message:

    The Google Maps API server rejected your request. The "client" parameter specified in the request is invalid.

  • The Earth API will display this message:

    The Google Maps API key used on this web site was registered for a different web site. The developer of this web site can generate a new key here.

  • The Static Maps API V2 and the Street View Image API will not display any error message. However, requests for these APIs that use a client ID from an unauthorized URL will not be covered by the Google Maps API for Business SLA and will not be eligible for technical support.

The net effect is that users will not be able to use features that depend on the Maps JavaScript API V3 or V2, the Maps API for Flash or the Earth API.

Removing the client ID from the application will work around this problem, but by doing so you will lose all the Maps API for Business privileges for that application. This means you will not be entitled to:

  • A robust Service Level Agreement (SLA).
  • Customer support.
  • Increased limits on Web Services.
  • Commercial-grade terms and conditions.
  • Intranet application support within the enterprise.

This means that applications that are internal-only or non-free and do not use a valid Maps API for Business client ID correctly will not be compliant with the free Maps API Terms of Service.

As a result, removing the client ID is most often not a valid fix.

The Solution

The correct way to solve this is to find and authorize the right URLs to use your client ID.

In most cases, you need to authorize an application to use your client ID. Applications often use multiple URLs that share a common pattern, e.g. a store locator can live at example.com/stores or at stores.example.com. You need to find a URL that will match all URLs your application uses.

Note: Authorizing www.example.com will not authorize stores.example.com or any other subdomain of example.com.

Each URL you authorize can be as specific as a single web page or as generic as an entire domain, including its subdomains. Please see Registering authorized URLs for more information. We recommend authorizing URLs that match a fairly broad set or URLs, as long as you administer them.

Note: We recommend against authorizing a whole domain unless your organization has full control over all of that domain's content. For instance, authorizing the whole blogspot.com domain would enable everybody to use your client ID, at your expense, from that domain. Instead, you would want to authorize only a specific blog, e.g. googlegeodevelopers.blogspot.com or even a specific page in that blog.

How to find the correct URL

Normally you would find the URL in your browser location bar. On public web sites that do not use <iframe> tags, this is usually easy. If in doubt, you can use the approach below for verification.

Complex applications may load the Maps APIs from a URL other than the one in the users location bar. This would be the case with <iframe> tags or when the URL of the page that loads the APIs is generated dynamically on the server and then sent down to the browser. Finding the correct URLs in these cases requires inspecting certain HTTP requests from the browser to Google servers.

The URL that needs to be authorized is the one in the Referer header for the requests the browser sends to Google to load the API. Each API is loaded from a different URL:

All requests to maps.googleapis.com may be sent to maps.google.com or maps-api-ssl.google.com depending on how the application is set up to load the API. Therefore, when looking for the above requests, it is usually the path (in bold) which is important.

From HTTP headers in your browser

Before you can inspect the Referer header in the above requests, you first need to capture them from your browser. Several tools are freely available to capture HTTP headers in all major browsers:

Note: You need to tweak Fiddler2 in order to capture HTTPS traffic. Please see details here.

If you are unable to capture HTTP headers directly from the browser, you can try capturing HTTP traffic using a network protocol analyzer like Wireshark. This tool may be more complex to operate than the tools above, check some Wireshark tutorials on the web if you are not familiar with it.

Once you have your tool of choice, follow these steps to find the URL that needs to be authorized:

  1. Start the capturing tool. Make sure it is capturing HTTP requests from your browser.
  2. Point your browser to the application that is unable to load the Maps API using your client ID. You should receive one of the error messages described above.
  3. Stop capturing HTTP traffic. This makes it easier to inspect captured traffic.
  4. Find the request that tries to load the Maps API using your client ID. For instance, if your application tries to load the Maps JavaScript API V3, look for a request like:
    GET /maps/api/js?sensor=false&client=gme-yourclientid HTTP/1.1
  5. HTTP request headers follow immediately after that line, with no line breaks. Find one like:
    Referer: http://www.example.com/stores/find?zip=94043
  6. The URL in that line is the one that needs to be authorized to use your client ID.

Finding the common pattern

To be sure that the whole application will be able to load the Maps APIs using your client ID, you need to find a common pattern across all the URLs the application uses and authorize a URL that represents this pattern, following the rules explained in Registering authorized URLs.

This is often as simple as one directory (e.g. example.com/stores), or a subdomain (e.g. stores.example.com — these are often easy to deduce from just a couple of URLs.

When dealing with complex applications, you may need to repeat the steps above with a number of user-facing URLs that display a map. However, this may be too laborious and still result in an incomplete set of URLs. For such an application, its developers would likely be in the best position to provide the URL pattern.

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.