New oAuth2 authentication

hello Sachin Bansal ,
great work , but i got this error,
- Warning: file_get_contents(BR-Bs3nWMA34.....): failed to open stream: No such file or directory in gapiOAuth2->fetchToken() (line 619 of /docroot/sites/all/modules/contrib/ga_stats/inc/gapi.class.php).
- Invalid Google Analytics account details.

I applied the patches and entered a working path to the p12 file, but it still doesn't work. "Invalid Google Analytics account details." is there any more magic involved?
I also wrapped the file_path into drupal_realpath() to make private:// work.

I've follow the instruction and i got same error in #5
"Invalid Google Analytics account details."

I have not tested this patch, but for those experiencing authentication problems make sure you get the latest version of gapi.class.php at https://github.com/erebusnz/gapi-google-analytics-php-interface

If your server is using & instead of & as default query parameter then the version of gapi.class.php prior to June 1, 2015 will fail. See: https://github.com/erebusnz/gapi-google-analytics-php-interface/issues/118

Thanks dawansv. That was exactly the useful hint. With the newest gapi.class.php from yesterday the authentication is working on my machine.

@sachin, you might want to re-roll the patch against 7.x-1.x-dev, as it doesn't applies cleanly.

I'm using your patch on 7.x-1.0-beta2, and was able to successfully authenticate with GA (thanks for the instructions).
However, counts don't update properly... looking at the ga_stats_count table there is only one nid, and I have around 25k.
Also, I get the message "Counts updated" only when using "All Web Site data" profile in the GA Profile Selection. If I choose another property, updating counts gives me an error "Counts Not Updated - No Valid Google Analytics Data", even though I added service account in the Users list on that GA property with Read and analyze permissions.

I've also updated url column in ga_stats_count table to accept 2048 chars, per info in #2429093: Too long urls breaks the update. just to be sure.

Any idea of what might be going on?

@perke. Maybe it's https://www.drupal.org/node/1528162 ? It took me some time to find out, that all of my nodes were skipped, because the NID could not be extracted with language prefixes.

Awesome @szeidler!!! Many thanks for the heads up!
Had to manually apply patch but everything is up and running.
This has also fixed the issue of selecting the proper GA profile.

Cheers!

I'd say this can go to RTBC

Just found out that I was working in parallel on the same issue and here is my patch against 7.x-1.x latest version

Couple of differences from the original patch:
- it lets you save the p12 file, which contents are saved into the variable and then the p12 file gets physically removed
- for oauth2 api calls using library provided by google https://github.com/google/google-api-php-client

I am setting this back to Needs Review, since there is a new patch.

@extremal, good idea on file upload... just tested your patch on 7.x-1.x-dev and got WSOD on admin/config/services/ga_stats with this error in log:
"PHP Fatal error: Can't use function return value in write context in /sites/all/modules/contrib/ga_stats/ga_stats.admin.inc on line 34"

Note, I'm on PHP 5.3 and empty() needs to access value by reference (in order to check whether that reference points to something that exists), and PHP before 5.5 didn't support references to temporary values returned from functions. (taken from this StackExchange answer)

I've refactored patch #16.
Changes:
- Made sure that empty() can access variable by reference on php < 5.5 (Thanks @perke)
- Removed dependency on libraries module
- Removed google php library, as the gapi was updated to support oauth2
- File upload saves p12 file into the private files folder now (please make sure it is configured)

The patch is done against latest 7.x-1.x-dev

@extremal You forgot to remove debug info

+++ b/includes/ga.inc
@@ -13,7 +13,7 @@ function _ga_stats_update_counts() {
-
+print_R($data);

Good catch @george.karaivanov !
Re-rolling ..

If you are going to use the private file directory, then you really need to make that a requirement somehow. You can't assume that people will know to set that up before upating the module. And, I assume your code will throw some nasty errors if the private file storage isn't set up.

@RoloDMonkey Thanks for pointing this out.
I added a simple check which won't let you submit the form unless the private file system path is set.

Rerolled the patch to delete variable ga_stats_acct_type instead of ga_stats_profile

Rerolled the patch without libraries dependency

Can someone confirm what steps are required to get this working again?

I am very confused about what is going on with this module and how to get it fixed.

@joedevdrupal,
1. Update module to the latest 7.x-1.x-dev
2. Apply 2498117-25-ga_stats_oauth2.patch
3. Go to https://console.developers.google.com
4. Create a new project
- in the API section enable Analytics API
- in the 'credentials' section click on 'Create new Client ID' and choose 'Service account' with the key type P12
- save the P12 key and Client ID
5. On your site go to /admin/config/media/file-system and make sure that the 'Private File System Path' is configured
6. Go to /admin/config/services/ga_stats/auth and upload your P12 key and set the email address (it's the same as Client ID which you copied earlier from console.developers.google.com)
7. Add Client ID email into your google analytics account with permissions Read/Analyze

That should be it !

Rerolled the patch to not use drupal_realpath() so that the p12 file can be read in different environments.

It would be nice to include the gapi.class.php as a library rather than commit with the module, but this is up to the maintainers.

I followed the steps in #27 but the Google Analytics Statistics config page still tells me "Cannot select a tracking account until your Google Analytics account is configured."

A couple of things I noticed along the way:

• The Google Developers Console lists in the Service Account credentials a Client ID (which is NOT an email address) and an Email address. Neither one worked for me.
• Is it necessary to re-upload the p12 file each time you update the credentials?
• Google supplies a password for use with the key, but the module never requests it.

I'm happy to assist with this in any way possible. Thanks for your work to date in getting this update to the new authentication method.

One other thought: Is it necessary to implement a custom oauth implementation instead of leveraging an existing solution like the Oauth module?

Thanks @extremal. Will try that.

I have a conspiracy theory that Google is actively trying to kill Open Source in some ways..

For those having issues, please be sure to follow step #7 in comment #27 above. I had missed that step and was getting authentication errors. It's working now.

Thanks for fixing this issue. I've just made some testing and it's working pretty smooth.

But yet there is a weird issue - after some time (couple hours) the uploaded p12 key from the private directory had disappeared. And the module stops working. Any hints what could remove this file from directory?

Same here, .p12 key is being removed from private:// directory after some time. Couldn't figure out when exactly, first I thought it is due to some limitations with my hosting platform (site using this module is on Acquia Enterprise Cloud) but will have to investigate more.

+1 Perke #34
i got this error
"Warning: mkdir(): Permission denied in drupal_mkdir() (line 2413 of /mnt/www/html/******/docroot/includes/file.inc).
The directory sites/all/private does not exist and could not be created."

Great spot everyone! The garbage collection will remove temporary files.

I've rerolled the patch to ensure the p12 file is permanent:

$file->status = 1;
file_save($file);

I have to admit, I am leaning towards the solution proposed in #2498117-16: New oAuth2 authentication.

First, it doesn't require the private directory. I don't think we should ask people to go through setting up private file storage when storage in the database is (arguably) just as secure.

Second, it includes the Google-approved OAuth implementation as a library, which is a better way to go in the long run. However, I could be dissuaded from this since it also is an obstacle for administrators.

Related 7.x-1.x-dev seems to have a small bug in the implementation of hook_menu in a hurry so not doing a patch but lines 14 and 23 say

    'access arguments' => array('administer site config'),

and should say

    'access arguments' => array('administer site configuration'),

this resulted in a 403 error if I wasn't logged in with user uid 1

@ghankstef Should this be in a separate issue?

I can confirm that step 7 in #27 solved my issue. Also, the patch in #36 appears to work.

@davidgrayston for some reason that didn't worked for me

when running drush ga-stats-update I still get errors:

WD ga_stats: GAPI: Failed load key file "private://ga_stats_p12_key.p12". File could not be found.
[error] Invalid Google Analytics App authentication attempt.

Had to upload the file again.

Any ideas?

@perke you would have needed to upload the p12 file again after applying patch #36 as the previous temporary p12 file would have been deleted

Did it work after uploading the file again and has the p12 file persisted?

Yes, I uploaded file after the patching... It lasted for some time, more than 6 hours or so, and started throwing errors again.

The same for me as for @perke. I had to again re-submit the p12 file after some time.

Strange, I'm not having this issue – do you have any modules enabled that could be deleting unused permanent files?

We could add a ga_stats file usage entry for the p12 file to help prevent it being deleted?

Ok. Something weird is going on here. I uninstalled the module completely and installed the latest 7.x-1.x-dev.

I didn't apply the patch or any of the other steps. Drupal authenticated my GA account as usual and now everything is working as before without the error message. I confirmed that views is pulling in the list accurately.

Everything looks to be working as usual, no error messages...

Is this just a fluke, or has the latest 7.x-1.x-dev been updated?

@joedevdrupal No, we are experiencing the same thing. If we go into our sites and re-save our configuration, the old auth method has started working again.

I wonder how long this will last?

I apologize, but I found out that during patching I somehow omitted line with:
+ file_save($file);
So now I'm testing it to verify weird disappearance or not.

The issue of disappering the p12 file is gone, thanks guys for your help.

It works here too, 48 hours passed after patching with #36, stats are working and happily updating.

Changing title and status to better explain the issue and hopefully get the patch in the next release.

Thank davidgrayston for your patch , and thanks all for your works on this issue , Works fine with me patch #36.

Applied last patch but got WSOD and Parse error: syntax error, unexpected T_FUNCTION in /home/bval/domains/paris10.ru/sites/all/modules/ga_stats/includes/gapi.class.php on line 280

WSOD on some Admin pages. .p12 file was successfully saved.

I have php 5.2 if it might help.

Have to disable module :(

#27 does not work for me
Any ideas how to run it?

7.x-1.0-beta2+18-dev

Invalid Google Analytics authentication attempt.

This may be because I'm not the Analytics master account owner but have administrative rights and API rights?

I have the same problem

We are going to try this once getting back to this issue.

https://stackoverflow.com/questions/12837748/analytics-google-api-error-...

---

Yes this worked after working on it today. This link may also help https://developers.google.com/identity/protocols/OAuth2ServiceAccount#ov...

Thank you David for patch #36.

I have rerolled the patch to apply some coding standards, removing unused array, variables and white spaces.

Huge thanks for this patch and the directions in https://www.drupal.org/node/2498117#comment-10003057.

Thanks for the patches, I applied patch #36 because patch #57 hasn't been tested and reviewed yet. Feel free to submit a new patch with your changes on a new issue.
Also, I started branch 7.x-2.x, which features this patch.