ikerhurtado.com
You're in
Iker Hurtado's pro blog
Developer | Entrepreneur | Investor
Software engineer (entrepreneur and investor at times). These days doing performant frontend and graphics on the web platform at Barcelona Supercomputing Center

How to programmatically post on Google+

1 Dec 2014   |   iker hurtado  
Share on Twitter Share on Google+ Share on Facebook
In this entry I try to explain how to post messages on Google+ streams from the server -without need for user intervention at each request- through its API; but I get stuck on the way, I can not publish. I have a lowest level approach: I study the formation of HTTP requests; I do not use the libraries available for different languages. Also I link relevant related web pages.

In my opinion, the Google+ system is the most cumbersome of the three: despite using OAuth 2.0, the exchange of requests required and its complexity is remarkable.

My current need is to post messages occasionally in my account from the server. The peculiarity of the Google+ system for my goal is that I have to obtain and keep a refresh token. This will enable to get a temporary token for each session with the service.

The resources I have got informed are referenced below this post.

I go step by step:

Step 1: Obtain OAuth 2.0 credentials

In order to interact with Google+ API it's necessary to create the application credentials: client ID and client secret.

In my case, working with Google App Engine application, I get the credentials from Apliccation Settings in application panel. Click the Google APIs Console Project Number section and this takes you to the Google Developers Console.

There, press the bottom Create new Client ID, and choose the value web Application in the popup window option APLICATION TYPE.

Step 2: Authentication request

The first request required is used for the user to authenticate to the service and authorize the application to interact with his account and his data from that time.

The URL for this request is: https://accounts.google.com/o/oauth2/auth. The required parameter are (more detailed info):

client_id. The client ID string that you obtain from the Developers Console.

response_type. Value: code. In this initial request the response will be an authorization code that will enable us to move forward in the process.

scope. Set of Google APIs access permissions (divided by spaces) to be requested; these permissions will be showed in consent screen.

redirect_uri. URI where the response will be sent. It must match one of the values set in the Developers Console.

access_type. (opcional parameter) It specifies whether the application needs to access when the user is not present in the browser. With offline value, the application, without requiring the presence of the user is able to renew the access token that is usually required for each session (usually expire in one hour). This entails the return of a refresh token in response.

state. (pptional, but strongly recommended) I do not use it in my example in order to keep things as simple as possible.

It only remains to make up a simple GET request. Mine is:

https://accounts.google.com/o/oauth2/auth?
  scope=email&
  response_type=code&
  access_type=offline&
  redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fsocial-test&
  client_id=421105069842-gmflthauj1qgivfgt356k7ltu8.apps.googleusercontent.com

The only noteworthy in the example is the possible need to code in Percent-encoding some parameter values in the request. In the example, it can be seen with the param redirect_uri: http://localhost:8080/social-test

Step 3: Consent screen

After submitting the initial request, the authentication and authorization Google system handles, if necessary, to redirect the user to the consent screen to confirm that he gives requested permissions.

You need to fill the PRODUCT NAME and EMAIL ADDRESS fields. If you do not fill the second one you will get the next error: invalid_client no application name

Step 4: Gain the authorization code

The response to the request will be redirect to the URI (redirect_uri) supplied; and, if all was right, the authorization code will be sent like the value of code parameter in the response.

Continuing the example, the answer will have this form (no returns the status because it had not submitted):

http://localhost:8080/social-test?
  code=4/YF-O1y3bhNLMuZoYBi_XW4Efgt67.spE8iCefv70XoiIBeO6P2m9UnZYukAI

Step 5: Exchange the authorization code for the token

Once the code on our server it remains one last step: to launch an exchange request of the code for the refresh token, which is what will enable in the future to get access tokens in order to use the API without the user's presence.

This second request is a POST one and will be submit to: https://accounts.google.com/o/oauth2/token. The required parameters are, of course, the gained code (code), the client data: client_id and client_secret, the URI what the response will go (redirect_uri) and, finally, the grant_type with a fixed value: authorization_code

As a POST request, parameters are packaged in the body; in the format Content-Type specifies. Usually this is (and here too) application/x-www-form-urlencoded. Would be like this (line breaks included for readability):

code=4/VyrgfPzdi5cfptZe9TdNp89mWHh3.UqphRIvdwv0doiIBeO6P2m92WNkukAI&
client_id=421105069842-gmflthauj1qgivfgt356k7ltu8.apps.googleusercontent.com&
client_secret=EwQ6fWFtgHU456v749KGZ32I&
redirect_uri=http://localhost:8080/social-test&
grant_type=authorization_code
In this request I have sent the URI without Percent-encoding codification and it works.

The response will be in JSON format; something like this:

{
  "access_token" : "ya29.bgBq3qonm1hX3yEAAAGHt8SRPwiHGf3TnSnlAOJXeMZSC1tDzHFiIp52BqbCWhgEtgTC2Hyg0lzs9Baswbs",
  "token_type" : "Bearer",
  "expires_in" : 3600,
  "id_token" : "VeryLongString...",
  "refresh_token" : "1/t8HjKxYwZG3pnVgy3e56hYuio1ZfU8orsJhM8UqPJXo"
}

We truly care about only three. The access token is the string that enables us to make requests to any Google API (of which we have obtained the necessary permissions, of course). expires_in is the time in seconds which will be valid this token. Finally, the refresh token will allow us to easily obtain a new token into new sessions in the future.

Paso 6: Renovar el access token

As I said above, the access tokens have a fairly short life (about an hour) so it's a kind of http session token. If you want to make another request to an API hours or days after, you need to get a new token. Having obtained the refresh token previously allows us to get other access tokens in the future without the user presence.

Moving on to practice, this request is equal to step 5 one except for the parameters to send.

The required parameters are: the client data: client_id y client_secret, the refresh token and, finally, the grant_type with value: refresh_token.

The request body would be like this (line breaks included for readability):

client_id=421105069842-gmflthauj1qgivfgt356k7ltu8.apps.googleusercontent.com&
client_secret=EwQ6fWFtgHU456v749KGZ32I&
refresh_token=1/t8HjKxYwZG3pnVgy3e56hYuio1ZfU8orsJhM8UqPJXo&
grant_type=refresh_token

The response will be in JSON format; something like this:

{
  "access_token" : "ya29.cABVoHxJQQFgIyIAAADppF38LfV1fgUn24bDB2VDQJJWijk1JRBjLybk0WTL", 
  "token_type" : "Bearer", 
  "expires_in" : 3600, 
  "id_token" : "VeryLongString..." 
} 

Now I have the new access_token that was my goal.

Step 7: Publish request on Google+

I have found the way for publishing through HTTP API very cumbersome -there is not a detailed example in official documentation.

Conceptually I don't clearly understand the difference between an Activity and a Moment, but it seems only Moments can be inserted.

I have made up and sent requests to the service but I have just received errors. I do not know what the problem is. The request_visible_actions parameter is source of suspicion.

I give up for now.


Links

Resources about authetication and autotization:

This is the main resource; they explain precisely this setting and it's quite detailed: Using OAuth 2.0 for Web Server Applications - Google Accounts Authentication and Authorization — Google Developers

This is very comprehensive and detailed but not so specific like the previous. I found some useful detail that is not in the other: Using OAuth 2.0 for Login (OpenID Connect) - Google Accounts Authentication and Authorization — Google Developers

Other resource that can be useful. It explain Explica especially well the part of Create New Client ID (Step 1.7): Google+ Platform — Pure server-side flow for Google+ Sign-In

Regarding the Google+ API write request:

Moments - Google+ Platform — Google Developers

Moments: insert - Google+ Platform — Google Developers

Go libraries to access to the API: Hello Google+ - Google Developers Academy — Google Developers

Set up links:

App settings

Account Permissions - Account Settings

Google APIs Explorer

About the mysterious parameter request_visible_actions:

Google+ Sign-In Button reference - Google+ Platform — Google Developers

Issue 878 - google-plus-platform - request_visible_actions query parameter to oauth2 not giving permissions to insert activities - Google+ Platform - Google Project Hosting

Other links:

Debugging your Google OAuth 2.0 token when you get HTTP 401s or 403s | Ikai Lan says

[JavaScript] // first call gapi.auth.authorize with immediate:true: _checkAuth = function _ - Pastebin.com

Google+ Platform - APIs for Google Apps — Google Developers

Login with Google using OAuth 2.0 for iOS Xcode Objective-C | TechnoGerms


Hello to all  |  11:15 - 16 Mar
 |  16:47 - 17 Apr
adsd  |  16:47 - 17 Apr
 |  12:00 - 28 Apr
B Niranjan Yadav  |  05:23 - 27 Jan
Hi this is niranjan

POST A COMMENT: