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.

Patch has been updated. See below.


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)
new23.44 KB
new23.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
new27.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
-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