According to Google, OAuth 1.0 was official deprecated on April 20, 2012 (Google OAuth 1.0 Reference). They suggest migration to OAuth 2.0 as soon as possible.

The attached patch adds full OAuth 2.0 support while still ensuring full compatibility with all aspects of the Google Analytics Reports module.

The new implementation of OAuth2 kills the reports page thus. We rolled up all this functionality in one patch:

#1678306: Add Support for OAuth2 Authentication
#2368151: Build reports in Reports module on Views
#2169159: Migrate from Chart module to Charts

Members fund testing for the Drupal project. Drupal Association Learn more


grendzy’s picture

Thanks for the patch.

The downside of upgrading now is OAuth 2.0 is significantly more burdensome for the user, due to the need to "register" the app manually to obtain the client id / secret. (From what I can see, that's not an inherent weakness of 2.0, but a decision Google made to discontinue using the "anonymous" keys).

Since we potentially have until 2015, it's worth considering if the added ease of use justifies sticking with 1.0 for a while longer.

Alternatively, we might be able to create a throwaway google account, register the app once, and include the id / secret in the module's source code. From :

The client_id and client_secret obtained during registration are embedded in the source code of your application. In this context, the client_secret is obviously not treated as a secret.

jplaut’s picture

That is a good point regarding the ease of use of OAuth 1.0 as compared to OAuth 2.0. This complication seems unavoidable, however.

I looked into your suggestion and I think that creating a throwaway registration with installed app settings won't work. Given the redirect URIs that are automatically created in that case, the client would either need to be running their app on a local server or within an environment that could track when a new page is opened.

Perhaps the module could give users the choice whether to use OAuth 1.0 or 2.0. It seems like the added security and continuing support of OAuth 2.0 might be better for some users.

yaho’s picture

WSOD with this error after patching:

Fatal error: Call to a member function queryReportFeed() on a non-object in /home/www/********/www/sites/all/modules/google_analytics_reports/google_analytics_api.module on line 180


jplaut’s picture

Patch has been updated to improve post-authentication redirection.

jplaut’s picture

Another update to prevent WSOD when calling report query functions.

grendzy’s picture

Version: 6.x-1.x-dev » 7.x-3.x-dev
Status: Needs review » Needs work

I had a chance to talk with Google's developer relations last week. They gave us the go-ahead to code this as an installed application.

When you have a web application that is distributed then the best option is to treat it as an Installed Application. This is what others have used, for example in wordpress plugins, etc.

I don't think there is a full working demo of this approach (I have it on my list of articles to write). The flow would be along the lines of:
1) Create an APIs console project, Create a OAuth 2.0 client for Installed application. So the redirect uri is going to be urn:ietf:wg:oauth:2.0:oob
2) Form url for auth based on directions at
3) At some point you are going to present the admin/user with the option to "connect" their Analytics account which is them basically visiting the url formed in step #2. They will then be directed to Google accounts and prompted to auth and grant access to your Client/App. You can see the process yourself by forming a url and pasting it into your browser. For example:
4) If they grant access they will be given a code. You need to provide a box for the user to input the code, then the user can copy and paste this into the box you provide. From the user perspective their job is done once they've submitted the code to your application.
5) With that code you can then complete the rest of the flow and obtain a refresh token. Which is covered by the instructions under Handling the Response. You should store the refresh token which is long-lived and you can use this indefinitely to obtain access tokens (this is covered under Using a Refresh Token) which you use to access the analytics data (until the refresh token is revoked).
6) you also should include some handlers to cover the situation where the refresh token you've stored is no longer valid, just in case the user does revoke access at some point.

grendzy’s picture

I've registered the app, and this is our API access info:

Client ID:
Client secret: aSqdPmaoktHWfENAwwfs2ma_
Redirect URIs: urn:ietf:wg:oauth:2.0:oob

The quota is currently 50,000 requests per day, but Google is willing to raise the limit once the app is reviewed.

yaho’s picture

After patching from #5 works like a charm!

So thanks a lot! :-)

navarrete’s picture

Version: 7.x-3.x-dev » 6.x-1.3
Component: Code » API module
Category: task » bug
Priority: Normal » Major
Status: Needs work » Patch (to be ported)
23.44 KB
23.95 KB

I had many problems with connecting to Analytics these days. With the path changes of 6.x-1.3 version ( ) was not enought

But this parch with the paths modified works fine to me. And I think with a better conexion than 6.x-1.3 module version.

You must first enter the Google Analytics API console and create a kind of OAuth 2.0 authorization

-------------------------------------------------- ---------------------------
Client ID for web applications
Client ID: xxxxxxxxxxxxxxxxxxxx
Email address: xxxxxxxxxxxxxxxxxxxxx
Client secret: xxxxxxxxxxxxxxxxxxxxxx
Redirect URIs: http://your-domain/admin/settings/google-analytics-reports
JavaScript Origins: http://your-domain
-------------------------------------------------- -----------------------

Then we establish the connection with our client clientID and secret inside drupal module. With this kind of connection I get a Traffic reporting and quota information trough google api console . And you can set a higher limit requests per second and user than allowing other connection.

I leave the last version of the patch in two versions, both to modify on 6.x-1.2 and for 6.x-1.3

Andreas Radloff’s picture

Version: 6.x-1.3 » 7.x-3.x-dev
Status: Patch (to be ported) » Needs review
27.74 KB

Here is a patch for 7.x-3.x, it might be a bit rough since I've never looked through this module or this API before, it works for me though.

Andreas Radloff’s picture

@grendzy, is the quota per user of the app or for the app total? If it's the later I strongly think another approach is better, I'm using up my quota fast and that's just one (admittedly huge) site.

I also wonder if this will mean that an individual user does not have access to the api statistics / dashboard? This is a feature at least I appreciate. Maybe we could provide a setting for using either your preconfigured IDs or providing a own set of keys?

grendzy’s picture

Status: Needs review » Needs work

Thanks for picking up the patch. I do want to continue with the "installed app" approach as requested by the Google developer relations team. There will be a global quota, and a per-site quota. I have been told not to worry too much about the quota and that it can be raised in proportion to the size of our userbase.

Ease of installation for newbies is a priority for raspberryman and myself so we want the keys in #7 to be the default.

I agree that allowing advanced users to provide their own client ID makes sense. Ideally I'd like to see this under an "advanced" fieldset that's collapsed by default so new users understand the whole app registration process is not required.

drpl’s picture


I applied the "google_analytics_reports-oauth2_support_update_6.x-1.3_18.09.2012.patch" it's working fine with me.

but when It gives me limit exceeded at 10k.

GAFeed Object
    [response] => stdClass Object
            [request] => GET /analytics/v2.4/data?ids=ga%3A*****&dimensions=ga%3ApageTitle%2Cga%3ApagePath&metrics=ga%3Apageviews&sort=-ga%3Apageviews&start-date=2013-01-02&end-date=2013-02-01&filters=ga%3ApagePathLevel1%3D%3D%2Fnews%2F&start-index=1&max-results=6&v=2 HTTP/1.0
User-Agent: Drupal (+
Authorization: ******

            [data] => GDatadailyLimitExceededQuota Error: profileId ga:**** has exceeded the daily request limit.
            [protocol] => HTTP/1.0
            [status_message] => Forbidden
            [headers] => Array
                    [Content-Type] => application/; charset=UTF-8
                    [Date] => Thu, 31 Jan 2013 21:26:06 GMT
                    [Expires] => Thu, 31 Jan 2013 21:26:06 GMT
                    [Cache-Control] => private, max-age=0
                    [X-Content-Type-Options] => nosniff
                    [X-Frame-Options] => SAMEORIGIN
                    [X-XSS-Protection] => 1; mode=block
                    [Server] => GSE

            [error] => Forbidden
            [code] => 403

    [results] => 
    [meta] => 
    [queryPath] =>
    [totals] => 
    [error] => Code: 403 - Error: Forbidden - Message: GDatadailyLimitExceededQuota Error: profileId ga:**** has exceeded the daily request limit.
    [fromCache] => 
    [host:protected] =>
    [OAuthHost:protected] =>
    [access_token] => ****
    [refresh_token] => 
    [expires_at] => 
kalpeshhpatel’s picture

Hello I am facing the same issue. For version 7.x-1.3.

When I see report it shows the error of Method not allowed with error 405.

Can anyone suggest, how can I resolve it. I have tried the patch but it's not working.

-- Thanks

kalpeshhpatel’s picture

Issue summary: View changes

Updated patch.

Plazik’s picture

Assigned: jplaut » Unassigned
Issue summary: View changes

Google Auth module provides Google OAuth2 authentication. I think we should use this module.

Plazik’s picture

OAuth 1.0 for Google Accounts is going away
Starting April 20, 2015, OAuth 1.0 will no longer work for Google Accounts.

Luke_Nuke’s picture

So... after 3 days OAuth 1.0 will be shut off and this module will stop working? And I believe it's the main integration with GA API solution for Drupal right now, that is used by 12 784 websites. Bad times :( .

Luke_Nuke’s picture

Priority: Major » Critical
dobe’s picture

This is a reroll of #10 to current dev. I was able to revoke the access key re apply it and connect to grab the profiles on the config form. So I am assuming most should work. I have not checked views integration or anything.

dobe’s picture

Status: Needs work » Needs review
29.78 KB

Some updates. I have tested the views implementation and this patch resolves some issues uncovered from my previous.

Martijn Houtman’s picture

Applied patch #20, works fine for me. Please do not that if you use the reporting API in your custom module (as I do): the response structure has changed a bit, so check your code.

togbonna’s picture

Patch #20 apparently works. But I get the following warning when I try to view the Google Analytics Summary page under Reports:

You must authorize Drupal to use your Analytics account before you can view reports.

The configurations authenticates successfully, but for some reasons the summary report doesn't show.
What am I missing?

dobe’s picture

Ill look into this. I had not used the summary page.

dobe’s picture

I am guessing your having issues based on this: Can you give any details to if you applied this other patch? Etc.

dobe’s picture

I have combined all the patches so it is just one. It will hopefully make it easier for applying so we can get this to dev.

scotthooker’s picture

When updating using this patch. What should the redirect URI link be?

dobe’s picture

togbonna’s picture

Great! The combined patch on resolved the issue. Thanks.

Minor issues though: The summary page link no longer appears under the Reports menu. Had to go directly to the URL, 'admin/reports/google-analytics/detail' to access the page.

And I believe the page title should read 'Google Analytics Summary', instead of 'Content Detail', like before.

dobe’s picture

Clearing cache didn't fix it?

togbonna’s picture

No, it did not, but I noticed that the menu item '$items['admin/reports/google-analytics']' = array( ... ); is missing from google_analytics_reports_menu().

emerham’s picture

Settings wont save when selecting the site data to use. I have multiple sites on one Google account and it is only pulling session data from the first list in the list.

neale.wolfson’s picture

Status: Needs review » Needs work

Trying to get this up and running but well 'issues' :)

Big issue so far I've struct is the development of the return url. currentUrl()

We're running on Acquia infrastructure, so we have our ssl to the proxy server, and then standard to the server itself.
Secure is turned on, but the structure of the call is such that it totally messes up the return URL. (In short the return URL is

I'm not fully certain the best way to fix this one (To continue testing I've hard coded the address :) So I
m leaving it up to the folks here.

Smaller issue.
I think this might be an issue with the base Version but...

We're using multi domain code, and domain_conf. Because it's not loaded all the time the admin_form function is missing. (A include_once should do it)

And a comment.
Perhaps we could do with more checks on the responses we get from Google. I found I'd forgotten to turn on the API and that the error message generated by the system had 'disappeared' by the time it was returned to my code.

Apologies to giving more problems not solutions, I'm working to deadline and trying to either get it working fully, or putting it off til later.

bigmonmulgrew’s picture

I'm unable to set a profile Attempting to set a profile also generates 2 errors.

Notice: Undefined index: google_analytics_reports_profile_id in google_analytics_reports_api_admin_submit() (line 183 of /var/www/sites/all/modules/google_analytics_reports/google_analytics_reports_api/

Notice: Undefined index: google_analytics_reports_cache_length in google_analytics_reports_api_admin_submit() (line 184 of /var/www/sites/all/modules/google_analytics_reports/google_analytics_reports_api/

It refers to this code

variable_set('google_analytics_reports_profile_id', $form_state['values']['google_analytics_reports_profile_id']);
      variable_set('google_analytics_reports_cache_length', $form_state['values']['google_analytics_reports_cache_length']);

Sadly I don't know enough about this to help fix it but I thought I'd at least give some additional info.

Helgi Andri Jónsson’s picture

In the query parameters must be passed to drupal_goto in the second argument of the function as below:

   * Begin authentication by allowing the user to grant/deny access to the Google account
   * @param String $client_id
  public function beginAuthentication($client_id, $redirect_uri) {
    $url = $this->createAuthUrl($client_id, $redirect_uri);
    $array = explode("?", $url);
    $array2 = explode("&", $array[1]);
    $queries = array();
    foreach($array2 as $query) {
      $array3 = explode("=", $query);
      $queries[$array3[0]] = $array3[1];
    drupal_goto($array[0], array('query' => $queries));
dobe’s picture

This function seems to need to make use of drupal_parse_url() as well. I will see about messing with this a bit.

aparna_kondala’s picture

For setting profile, Please correct lines in

variable_set('google_analytics_reports_cache_length', $form_state['values']['google_analytics_reports_api_cache_length']);
variable_set('google_analytics_reports_profile_id', $form_state['values']['google_analytics_reports_api_profile_id']);
variable_set('google_analytics_reports_cache_length', $form_state['values']['google_analytics_reports_api_cache_length']);

craigshaddick’s picture

I ran into the same problem as aparnakondala123, have created a patch for it.

dnd’s picture

Hi, I've problem with connecting my site to google, when I try to run reports i get message like "You should authenticate this site to use your Google Analytics account before you can view reports".
I've done:
On site:
1. Get newest google analitics (
2. Run patch google_analytics_reports-oauth2-support_7.x-3.x_1678306-20.patch
3. Run patch google_analytics_reports-oauth2-support_7.x-3.x_1678306-37.patch
4. add modifications from (

On google:
1. Create web app
2. Get ids from app and use it to configure google analitics reports (drupal)
3. Validate site and connect it with google analitisc, confirming everything

On drupal I can see my reports but when I try to run reports it fails.
Please help! I've spend a lot of time with than I ve no idea what could be wrong.

dobe’s picture

@dnd check my comment #24, The parent issue contains the auth patch + the reports page patch.

emerham’s picture

dnd, if you are trying from the admin menu you need to add /detail to the end to get some of the data. There is a block you can add to a region and it will get the ga data for that page and there you can click a more link to get more information about that current page.

dnd’s picture

works .... thank you! it seems I've done everything ok and there is a problem google anlitics reports

I'm trying to solve it ... I've try to pach google_analytics_reports with but I've some problems, so I'm going to do it manualy (but maybe tomorrow :) today so tired (It's 00:00 in my time zone, and at 7:00 have to be at work ;)) Thanks! I'll report my work tomorrow.

lukee1234’s picture

how far away is a dev version with these updates?

Plazik’s picture

@Luke_Nuke after "Review & tested by community".

alemadlei’s picture

I had several problems applying the patch (whistespace errors) but in the end got it to work with SourceTree.

I had a problem though.

sites/all/modules/google_analytics_reports/google_analytics_reports_api/, protected function sanitizeReport.

$fields = google_analytics_reports_views_get_fields();

I removed that line. I don't need the reports module but this function was calling a function from that module.
The variable is used, but I don't seem to get anything wrong if I set it to an empty array.

Maybe the definition of those fields should be moved somewhere else, or the report module should be added as a dependency in the info file.

This is the process I followed:

  • Apply patch
  • Change variable names on settings form
  • Change all class from google_analytics_api_report_data to google_analytics_reports_api_report_data

Everything seems to to work as before.

dnd’s picture

After patching still doesn't work, but this time when run from admin/reports/google-analytics I ve blank page.
Maybe I ve made a mistake in patching.
Can someone send me patched version (working) ? (my email:
Thanks in advise!

alemadlei’s picture

@dnd, using latest dev, I applied #1 from did the changes and that worked for me.

togbonna’s picture

'Pageviews Over the Past 30 Days' chart values does not correspond with the one on Google Analytic dashboard page.

aotu’s picture

Patch #1 applied and authenticated successfully, however now there's no reports page at: /admin/reports/google-analytics

Does anyone have a fix?

togbonna’s picture

@aotu, go to /admin/reports/google-analytics/detail. No menu link though

dreamet’s picture

I have applied patch #10 but I am getting error.

Notice: Undefined index: HTTPS in GAFeed::currentUrl() (line 72 of /home/.................modules/google_analytics_reports/

and the watch dog displays
Code: 401 - Error: Unauthorized - Message: { "error" : "unauthorized_client" }

How can I get the full workable full package of this module?

dobe’s picture

Issue summary: View changes

You will have a better shot going to:

dreamet’s picture

dnd, can you describe for me how? Patch google_analytics_reports-7.x-3.0-beta1 by using
1. Run patch google_analytics_reports-oauth2-support_7.x-3.x_1678306-20.patch
2. Run patch google_analytics_reports-oauth2-support_7.x-3.x_1678306-37.patch

There is no GAFeed.lib file in google_analytics_reports-7.x-3.0-beta1. can you help please or can you send?

igasi’s picture


dreamet’s picture

@Andreas Radloff, I have applied #10 for version 7.x-3.0-beta1 but still I am getting error. Can someone send me patched version (working) ? (

Notice: Undefined index: HTTPS in GAFeed::currentUrl() (line 72 of /home/.................modules/google_analytics_reports/

and the watch dog displays
Code: 401 - Error: Unauthorized - Message: { "error" : "unauthorized_client" }

dreamet’s picture


GreenReaper’s picture

Any love for 6.x-1.3, or a chance for a 6.x-1.4/2.0?

I tried applying the patch in #9 and it went on cleanly and even let me get an authentication page at Google once I'd figured out that I had to turn on the Analytics API.

However, when I returned to the site, although it *said* "You have been successfully authenticated.", I got this in the error log:
Code: 400 - Error: Bad Request - Message: { "error" : "redirect_uri_mismatch" }

dreamet’s picture

I am trying to OAuth2 Authentication and I am getting redirect_uri_mismatch error. My correct url is but I am not sure why redirecting to Please help.

Error: redirect_uri_mismatch

The redirect URI in the request: did not match a registered redirect URI.

dobe’s picture

Is https setup on your website? If not you might want to try http. Port :80 is usually not a ssl port.

dreamet’s picture

Yes https setup.

dobe’s picture

@dreamet have you downloaded latest dev and applied patch(s) at

dreamet’s picture

@dobe, yes I applied patch and fine in my local but when I go live the redirection still appending :80.

What should I do if the https setup on server side? do you have any quick solution? Please I am running out of time.

Thank you in advance!

TomDude48’s picture

I actually had the same problem with the redirect hosts on some of our servers. I added a config setting to override redirect host. Here is a patch to enable the override.

Pls’s picture

For anyone digging here and combining patches, here's one combined patch I uploaded to test it out faster - Cheers for great work implementing OAuth2 guys!

cjamesrun’s picture

Any chance at all that this can be ported back to the 6.x release for OAuth 2.0?

dreamet’s picture

@TomDude48. Thanks a lot. That is cool!

RumyanaRuseva’s picture

The patch from #9 worked perfectly for the 6.x-1.3 version.
The only tricky part is not to forget to set the correct Redirect URI when setting up the new client id.

attheshow’s picture

I was able to bypass the port 80 issue with the following edit to

$redirect_uri = GoogleAnalyticsReportsApiFeed::currentUrl();


$redirect_uri = GoogleAnalyticsReportsApiFeed::currentUrl();
$redirect_uri = str_replace(':80', '', $redirect_uri);
MrDaleSmith’s picture

Just to comment that Google have now removed Oauth 1 support entirely: I've installed the dev release of this module but authorisation takes you through to a Google issue saying Oauth 1 is no longer supported.

powysm’s picture

I stumbled about with this a bit so these are the steps i needed to update hope it helps someone else. (Have not checked out zip)

  1. remove google analytics reports and api modules
  2. install the 7.x-3.0-beta1 dev version
  3. patch it using this google_analytics_reports-oauth2-support_7.x-3.x_2488754-14.patc
  4. enable views, api and reporting
  5. clear cache
  6. change my code
    • from google_analytics_reports_oauth_token to google_analytics_reports_api_access_token
    • from google_analytics_api_report_data to google_analytics_reports_api_report_data
  7. Create client id and secret

Thanks to all other who contributed, which helped me.

mikegoodwin’s picture

It seems like one of my sites which uses this module has also been bitten recently by Google shutting off support of OAuth v1. What is the best approach to getting this module working with OAuth v2?

Plazik’s picture

Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.