Re: Having Issue with AdSense API authentication for devices

[Sérgio Gomes]

Hi Michael,

Any chance you could give "https://www.googleapis.com/auth/adsense" instead a try and see if that works?

Cheers,

Sérgio

---

Sérgio Gomes

Developer Relations

Google UK Limited

Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ

Registered in England Number: 3977902

---
On Tuesday, June 26, 2012 10:46:56 AM UTC+1, Michael Ormonde wrote:

Hey all,

I'm trying to implement a new account into the AdSense API application I'm developing, and I'm having issues adding the scope. I've previously added accounts in this way, but when I try to perform the following, I just get an "invalid_scope" response

curl -d "client_id=123456789.apps.googleusercontent.com&scope=https://www.googleapis.com/auth/adsense.readonly" https://accounts.google.com/o/oauth2/device/code

The unusual thing is that if I change the scope to something like https://www.googleapis.com/auth/userinfo.email it returns me the device_code, user_code successfully. I've been basing my request on https://developers.google.com/accounts/docs/OAuth2ForDevices and as I mentioned, I've previously authenticated devices in this way

Any help would be very much appreciated

Michael

[Sérgio Gomes]

Hi Michael,

Any chance you can send me the resulting HTTP request? I'd like to take a look at the headers and body in it to make sure everything is in order.

Cheers,

Sérgio

---

Sérgio Gomes

Developer Relations

Google UK Limited

Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ

Registered in England Number: 3977902

---

On Wednesday, June 27, 2012 8:57:29 AM UTC+1, Michael Ormonde wrote:

Hi Sergio,

I've tried that as requested, and still get the same "invalid_scope" error response:

curl -d "client_id=123456789.apps.googleusercontent.com&scope=https://www.googleapis.com/auth/adsense" https://accounts.google.com/o/oauth2/device/code

{

  "error" : "invalid_scope"

}

Michael

[Sérgio Gomes]

Hi Michael,

Apologies for the delay. From the log, it looks like the parameters are being passed as part of the body, which is probably not the correct way of doing things, although I'm not an expert on the low-level OAuth 2.0 protocol.

Is there any chance you could use an OAuth library instead (or better still, one of the Google API client libraries)? That would make your development a whole lot easier, as you'd be dealing with these matters at a much higher level. What environment are you coding for?

Cheers,

Sérgio

---

Sérgio Gomes

Developer Relations

Google UK Limited

Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ

Registered in England Number: 3977902

---

On Wednesday, July 4, 2012 9:23:20 AM UTC+1, Michael Ormonde wrote:

Just wondering, is there any further insight into this?

On Thursday, 28 June 2012 17:41:38 UTC+1, Michael Ormonde wrote:

I've run the curl request with the -v option. If you need anything else, or if this isn't waht you meant, please just let me know:

curl -v -d "client_id=123456789.apps.googleusercontent.com&scope=https://www.googleapis.com/auth/adsense.readonly" https://accounts.google.com/o/oauth2/device/code

* About to connect() to accounts.google.com port 443

*   Trying 173.194.78.84... connected

* Connected to accounts.google.com (173.194.78.84) port 443

* successfully set certificate verify locations:

*   CAfile: /etc/pki/tls/certs/ca-bundle.crt

  CApath: none

* SSLv2, Client hello (1):

SSLv3, TLS handshake, Server hello (2):

SSLv3, TLS handshake, CERT (11):

SSLv3, TLS handshake, Server finished (14):

SSLv3, TLS handshake, Client key exchange (16):

SSLv3, TLS change cipher, Client hello (1):

SSLv3, TLS handshake, Finished (20):

SSLv3, TLS change cipher, Client hello (1):

SSLv3, TLS handshake, Finished (20):

SSL connection using RC4-SHA

* Server certificate:

*        subject: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=accounts.google.com

*        start date: 2011-07-21 00:00:00 GMT

*        expire date: 2013-07-18 23:59:59 GMT

*        common name: accounts.google.com (matched)

*        issuer: /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA

* SSL certificate verify ok.

> POST /o/oauth2/device/code HTTP/1.1

> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5

> Host: accounts.google.com

> Accept: */*

> Content-Length: 104

> Content-Type: application/x-www-form-urlencoded

>

> client_id=123456789.apps.googleusercontent.com&scope=https://www.googleapis.com/auth/adsense.readonlyHTTP/1.1 400 Bad Request

< Cache-Control: no-cache, no-store, max-age=0, must-revalidate

< Pragma: no-cache

< Expires: Fri, 01 Jan 1990 00:00:00 GMT

< Date: Thu, 28 Jun 2012 16:38:53 GMT

< Content-Type: application/json

< X-Content-Type-Options: nosniff

< X-Frame-Options: SAMEORIGIN

< X-XSS-Protection: 1; mode=block

< Server: GSE

< Transfer-Encoding: chunked

{

  "error" : "invalid_scope"

* Connection #0 to host accounts.google.com left intact

* Closing connection #0

* SSLv3, TLS alert, Client hello (1):

Thanks for all your help with this Sergio :)

Michael

[Sérgio Gomes]

Hi Michael,

What device are you developing for (are you just using PHP for testing)? I may be able to point you to a library to make your life a lot easier with auth :)

Cheers,

Sérgio

---

Sérgio Gomes

Developer Relations

Google UK Limited

Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ

Registered in England Number: 3977902

---

On Thursday, July 5, 2012 11:22:16 AM UTC+1, Michael Ormonde wrote:

This may help too. Looks like similar issue reported for the Tasks API... Unusual as I had used this flow on the AdSense Managemet API before (although that was back in December last year)

https://groups.google.com/forum/?fromgroups#!topic/google-tasks-api/15PxeE89WCo 

Again Sergio, I appreciate all the time you're taking to look into this :)

Michael

On Thursday, 5 July 2012 10:23:31 UTC+1, Michael Ormonde wrote:

Just as an update to this, I tried to submit the post request via a form also to ensure my curl request wasn't at fault. Again, I found that I was getting the "invalid_scope" response. This didn't happen when I substituted the scope for " https://www.googleapis.com/auth/userinfo.email"; when I used that scope, I was able to complete the authorisation process (although obviously that scope isn't useful if I want to access adsense data :)

Michael

On Thursday, 5 July 2012 09:57:10 UTC+1, Michael Ormonde wrote:

Hey,

No worries. I'm currently developing for PHP. My understanding (which I admin is limited on the matter) was that I had to retrieve a device code and get the account to authorize access before the API calls can make the necessary requests as explained in https://developers.google.com/accounts/docs/OAuth2ForDevices. I'll keep digging around and will update here if I figure out what I've been doing wrong. I'll look into the actual library code too and see if there's specific functions for what I'm looking for

Thanks,

Michael

[Sérgio Gomes]

Hi Michael,

In that case, you should be using OAuth 2.0 for installed applications instead, and storing the refresh token between uses (so that you only have to grant permissions once). I'm not entirely sure whether switching to this will fix your problem, but it's worth a shot!

Cheers,

Sérgio

---

Sérgio Gomes

Developer Relations

Google UK Limited

Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ

Registered in England Number: 3977902

---

[Michael Ormonde]

I had been storing the refresh token to do future requests (I've had this working on several accounts for a couple of months), the problem was the device authorisation didn't seem to be working whereas it had before. However, I tried the different flow you suggested above for installed applications, and the auth flow on that page worked for me :) I was able to authorise the new account, and once I completed the response handling, I got back the same access/refresh tokens I'd gotten for my other accounts using the device method

Thanks so much for your help with this, I'd wouldn't have thought to try a different auth process without your suggestion

All the best,

Michael