I'm having an issue with the module and I'm hoping someone can clarify what is actually going on. I'm able to install, authorize and configure Google Analytics Reports without any issue. I can view the reports and everything seems to be working just fine. However, after a day or two my reports no longer show up and I get this error in the watchdog:

Code: 401 - Error: Unauthorized - Message: GDataauthErrorAuthorizationInvalid Credentials

Is this happening because my OAuth token is expiring? In my OAuth module the token lifetime is set at 7200 and the "Enable the oauth provider" check box is ticked.

If my token is expiring, is this expected behavior? Do I have to re-authorize the module every 7200 seconds? Is there some way to automate this re-authorization?

If there is a place in the doc that describes all of this, please just point me to it. I've looked but I can't seem to find anything. I'd really like to use this module for my sites but having to re-authorize it every 7200 seconds is more work than just logging into GA for the data.

Comments

johns996’s picture

I've been thinking about the issue I reported with the module and I've come to the conclusion that it is probably being caused by my multi site setup. I use a shared codebase and a primary Drupal database with all of my sub-sites having other database with just the site-specific tables included (cache, node, variable, etc).

What I've noticed is that when I go into my sites I can authorize one, two or all 148 of them and they all work just fine until a certain amount of time has passed. That amount of time, I'm fairly sure, is the token lifetime. Once that lifetime expires the sites stop showing reports and give me the 401 error mentioned above.

I've seen this behavior happen again and again each time I come back to test this module (my employer really wants it to work). This time, however, I noticed that the last set I authorized and set up continued to work well past the token lifetime (it has been working for over a week now).

I've come to the hypothesis that the fields in the variable table are at the root of my problems:

google_analytics_reports_cache_length
google_analytics_reports_hd
google_analytics_reports_oauth_token
google_analytics_reports_oauth_token_secret
google_analytics_reports_profile_id

When I compare these fields between to different Drupal databases, I see that the google_analytics_reports_cache_length and google_analytics_reports_hd fields are the same. The google_analytics_reports_profile_id matches the GA profile that I selected after I authorized the site. So I'm guessing that those three fields are not causing the issue.

What I think is happening is each time I authorize a new site, the google_analytics_reports_oauth_token and google_analytics_reports_oauth_token_secret fields are getting new keys from Google and at the same time wiping out all of the old keys on Google's servers. (I don't really know how this is all working, I'm just making guesses here.) Therefore, whichever site I authorize last is going to be the only site with the proper keys in these two fields. This is why when the token expires, only the last authorized site can correct go out to google and get a new token.

I'm hoping that I can just copy the google_analytics_reports_oauth_token and google_analytics_reports_oauth_token_secret keys across all of my sites and everything will magically work. Hopefully a dev or someone smarter than me can comment on the likely hood of this actually working. Regardless, I wanted to share my thoughts here in case some other poor multi-site admin was having similar issues.

grendzy’s picture

This is a mystery to me, OAuth 1.0 tokens never expire as far as I know. The oldest site I have GA deployed on has been running continuously with the same token & secret since May 2011.

When a site stops working, is the Drupal module still listed at google.com --> Account --> Security --> Authorized applications? If not, that might indicate another process or person is explicitly revoking the tokens.

Another small thing, make sure your server has an accurate clock synced over NTP. OAuth transactions will fail if the time is too far off.

johns996’s picture

Thanks for the reply grendzy. In response to your question, yes the Drupal module is still listed at google.com as an authorized application.

What's happening is each time I go to a different site, in my multi-site install, and authorize that site it generates a new OAuth token/secret and then stores this in that site's variable table. On the google accounts side however, I still only see the one application authorized even though I've repeated this authorization process for 10+ sites. This leads me to believe that google is generating a new token/secret each time I authorize a site but that token/secret is overwriting the last one on Google's end because I only have that one "authorized application" showing up on the Google accounts page. This makes sense because all of my multi-sites are on the same domain, they have a different directory (drupal.org/site1, drupal.org/site2, etc) after the domain name.

My theory, as I stated in my last post, is that the site I authorize last is the only one that ends up having the correct token/secret. I've tested this theory on my development server and my live server and it seems to hold true in both cases. It has been five days since I authorized a site and then copied that token/secret across all of my other sites and everything is working as intended.

My one suggestion for the module would be to move these two database entries (token and secret) out of the variables table and into a table that could easily be shared in a multi-site install. I'm sure this is not as easy as it sounds and I have no idea what table would be the "best" one to hold this data but I wanted to put that suggestion out there just in case.

Again, thanks for your response and thanks for the great module.

grendzy’s picture

One option, if you need to set some variables for all multi-sites, you can add it to the global $conf in settings.php:
$conf['google_analytics_reports_oauth_token'] = '12345';

I agree your observations suggest something might be getting overwritten on google's end. Weirdly, that hasn't been my experience, I use the same account for my company's website and local testing of the module, and have never seen a token revoked.

I haven't tried this, but it would be a good experiment and might make it easier to track the authorizations on Google's end:

--- a/GAFeed.lib.inc
+++ b/GAFeed.lib.inc
@@ -98,7 +98,7 @@ class GAFeed {
     $params = array(
       'scope' => 'https://www.googleapis.com/auth/analytics.readonly',
       'oauth_callback' => url('google-analytics-reports/oauth', array('absolute' => TRUE)),
-      'xoauth_displayname' => t('Google Analytics Reports Drupal module'),
+      'xoauth_displayname' => t('Google Analytics Reports Drupal module @ ') . url(''),
     );

     $this->query($this->queryPath, $params, 'GET', array('refresh' => TRUE));

If you have an opportunity to try that, I'd be interested in the results.

johns996’s picture

First of all, thanks for the tip about setting variables in the settings.php file. I made an include file and tacked it on the the bottom of all of my settings.php files and things are working nicely.

I also made the tweak you suggested and here are the results.

After revoking access and re-authorizing, this is what I saw on the google accounts page (https://accounts.google.com/IssuedAuthSubTokens)

Google Analytics Reports Drupal module @ /site1/ — Google Analytics

I revoked that access and then authorized another site and saw this:

Google Analytics Reports Drupal module @ /site2/ — Google Analytics

Is that what you expected to see? If there are any other tests you would like me to run, just let me know and I would be happy to help.

jitumiet’s picture

Issue summary:View changes

Hi johns996

I have revoked the access but I am not able to re-authorizing. Could you please suggest me how to reauthorize my "google analytics" module.

Plazik’s picture

Version:7.x-1.3» 7.x-3.x-dev
Component:Reports module» API module
Status:Active» Postponed (maintainer needs more info)

7.x-1.x version is unsupported. Try the latest 7.x-3.x-beta2 verion.