Google plus insert moment stopped working using google-api-dotnet-client

Question

The question is: Is there a new way in calling the API so an activity can be inserted into a user's profile?

I posted a related question here about a month ago. It was working fine until early this week when it suddenly stopped working and complained about this error:

[error message]

Error occurred while sending a direct message or getting the response

[inner exception]

The remote server returned an error: (400) Bad Request.

[stack trace]

at DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest request, DirectWebRequestOptions options)

at DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest request)

at DotNetOpenAuth.Messaging.Channel.GetDirectResponse(HttpWebRequest webRequest)

at DotNetOpenAuth.Messaging.Channel.RequestCore(IDirectedProtocolMessage request)

at DotNetOpenAuth.Messaging.Channel.Request(IDirectedProtocolMessage requestMessage)

at DotNetOpenAuth.OAuth2.ClientBase.UpdateAuthorizationWithResponse(IAuthorizationState authorizationState, EndUserAuthorizationSuccessAuthCodeResponse authorizationSuccess)

at DotNetOpenAuth.OAuth2.WebServerClient.ProcessUserAuthorization(HttpRequestInfo request)

at GPlusWrapper.PlusWrapper.GetAuthorization(WebServerClient client) in \gplus_csharp_ssflow\PlusWrapper.cs:line 122

at Google.Apis.Authentication.OAuth2.OAuth2Authenticator`1.LoadAccessToken()

at Google.Apis.Authentication.OAuth2.OAuth2Authenticator1.ApplyAuthenticationToRequest(HttpWebRequest request)
at Google.Apis.Requests.Request.CreateWebRequest(Action1 onRequestReady) at Google.Apis.Requests.Request.ExecuteRequestAsync(Action1 responseHandler) at Google.Apis.Requests.ServiceRequest1.GetAsyncResponse(Action1 responseHandler) at Google.Apis.Requests.ServiceRequest1.GetResponse() at Google.Apis.Requests.ServiceRequest`1.Fetch()

At first glance one that is experienced in Google API and DNOA would say it's a DNOA issue. I've been searching for three days and the issues that I found having the same error message does not fit the issue - or the solution proposed does not fit the issue I have.

So the next thing to do is to upgrade, yes, it make sense as the Google team may have changed something on how the API works. So I upgraded from v1.2.4737.25316 to v1.3.0.15233, which is the latest stable version in the repo.

To make sure that it is not my code or something in my code that causes the issue, I've revisited Gus' sample code given here. That sample code used to work in v1.2 but also stopped working in both v1.2 and v1.3.

Now since there is a new version of the library, it only make sense to re-visit the docs and see if something changed in the configuration or how to call the API. There seems to be nothing different in the way the API should be called.

So I did what I did the last time in debugging the application. I tried both

• request_visible_actions; and
• requestvisibleactions

and I still had the access_type parameter and nothing worked.

Again, my question is: Is there a new way in calling the API so an activity can be inserted into a user's profile?

Please take note that I am using the server-side flow

Answer 1

If you have the quickstart working, you can make API calls for writing app activities. To test this, find the following line of code in the quickstart:

ps = new PlusService(authenticator);

At this point, if you've successfully authorized, you can create a moment object and write it to Google:

Moment body = new Moment();
body.Target = new ItemScope();
body.Target.Url = “https://developers.google.com/+/web/snippet/examples/widget”;
body.Type = “http://schemas.google.com/AddActivity”;
ps.Moments.Insert(body, “me”, MomentsResource.Collection.Vault).Fetch();

I just tested the code, it still works, which means that the library is still able to make API calls. On second glance, I remembered you had asked this before, which makes me wonder if it's something specific to the SS flow. After a little debugging, I'm encountering the same issue as you running SS, however, the client is receiving the authorization code - a good sign. The client library is failing even though I'm removing the hack to pump in request_visible_actions - a bad sign.

Using request_visible_actions is still correct and underneath the hood, the client library is using the OAuth V2 flow, which should not have changed.

Final update:

I changed my example server-side demo to manually exchange the authorization code for the access token / refresh token. Please grab it again from GitHub to see if that helps but this is a quick and dirty temporary fix. I'll look into why the client library is breaking on the code exchange part.

P.S. I'm aware of the v1.3 changes, hopefully I'll make the time to perform the code updates soon! I thought nobody would notice...