0

I need to simply do this:

I need my application to use OAuth to get a user's full name, email address, gender and date of birth from Google.

I've got the whole deal about how to use OAuth. I've got the workflow and I could myself use the HttpWebRequest or the HttpClient to make requests myself and do it the raw way, which I actually prefer.

But, just to be safe, I want to use the Google API Dot Net Client. I have been reading through the vast amount of documentation about using this monstrous thing and I can't figure out a few basic things:

1) Which Google API do I need to use? Just the Google OAuth API will do? I see in the google dot net client library samples that they all get data from other Google services such as the Drives or Books services/APIs.

If I need just the basic information such as full name, email, gender and date of birth, which service do I need to query using the Google OAuth API?

2) Which NuGet package must I install? There're plenty of them with roughly the same names.

I've read a ton of stuff in the last 2 days about this and there are about 28 tabs open in my browser about this. The more I read, the more it adds to my confusion.

The NuGet package pages on the nuget website have no documentation at all. They must clearly state the purpose and the extent of services that the package provides. The latter is clearly missing. They all seem to have the same one line description instead, which is totally unhelpful.

I even took the source for the google-api-dot-net-client and tried compiling it. I didn't even know which Visual Studio version it was going to open in. I read the solution files in Notepad and they suggested that the version of 2012. So when I opened the solution in Visual Studio for Web 2012 Express, many projects did not open; it said they were incompatible with the version of Visual Studio. Also, the dependencies/references weren't loaded correctly.

I am using Windows 7 Home Premium. I've got Visual Studio Express versions from 2008 to 2013.

I need to use the OAuth API in an ASP.NET MVC application. I've seen various samples. I just need to know the basic set up information such as which binaries and which NuGet packages I need to get and from where.

Update

Hurray to hand-plumbing. I'm doing it by hand. Ditch the .NET client.

enter image description here

Water Cooler v2
  • 32,724
  • 54
  • 166
  • 336

1 Answers1

1

All Google.Apis NuGet packages are auto generated. As you can see there are packages for Drive, YouTube, Plus, Storage, AdSense, etc. You can read more about each package in our developers.google.com site. Take a look at the following:

  1. https://developers.google.com/api-client-library/dotnet/ - Contains all the documentation for the .NET client library for Google APIs.
  2. https://developers.google.com/api-client-library/dotnet/apis/ - Contains all the different Google APIs and several references to the API documentation, how to download it using NuGet, etc.
  3. Check out our https://developers.google.com/api-client-library/dotnet/guide/aaa_oauth page. It contains a lot of information about the OAuth 2.0 protocol and several snippets

In addition, just to let you know, you don't need to use any of that:

https://code.google.com/p/google-api-dotnet-client/source/browse/ contains only the core library code that is shared between all those different APIs. All APIs shared the same OAuth 2.0 protocol, the same HTTP components, the same media upload and download mechanism and so on. Every week I update the NuGet packages by running the NuGet publisher.

Hope it makes sense now.

peleyal
  • 3,472
  • 1
  • 14
  • 25
  • Thanks, Eyal. I'd gone through all the links you've shared and even your own blog and the articles there before posting this question. I still have difficulty tying all the bits together and the information I am looking for seems to me to be elusive. I am a person who can't live with abstractions. I have to dissect an abstraction and poke into it and see what's happening under the covers before I use it. I'd downloaded the binaries and started reading the source in Reflector since I couldn't get to open the source solution files. I have read most of the source and have decided to...contd.. – Water Cooler v2 May 21 '14 at 09:11
  • I've read most of the source and decided to do it the raw HTTP way, i.e. fire my own HTTP web requests and receive the authorization code myself, then ask for the access token using the same HTTP request way, and then store the token and refresh token myself and make another request for the stuff I want, once again using the HTTP way. I find that gives me a bit more control over what I am doing. – Water Cooler v2 May 21 '14 at 09:12
  • All the library's code is open source, I'm not happy to hear that you're not using my library, and I'll be happy to understand why so may other users in the future will avoid creating their own HTTP requests. Please let me know. If you need the source code of the generated API you can find it using the following: https://google-api-client-libraries.appspot.com/download/library/[API_NAME]/[API_VERSION]/csharp - Just replace [API_NAME] and [API_VERSION]. Hope it is helpful for you. – peleyal May 21 '14 at 18:41
  • Hi Eyal, I am sorry that you're upset. Please don't be. Your effort in producing that API is praiseworthy, to say the least. I have gone through the source code for the API. There are some reasons I am not using the API and I would list them at some time and send them to you. Off the top of my head, here's an incomplete list. – Water Cooler v2 May 21 '14 at 18:52
  • 1) The names such as GoogleAuthorizationCodeFlow and IAuthorizationCodeFlow are not very intuitive. The XML documentation of these items also is a bit wanting. For example, the documentation says, "The code flow," or something to that effect and brevity. And that isn't very helpful. I read more of the code to understand what your intention was, but code should clearly state intention itself. – Water Cooler v2 May 21 '14 at 18:56
  • 2) Having grown accustomed to using the Microsoft API, which are very expressive and their documentation on MSDN is comprehensive and very easy to understand, as a matter of personal preference and taste, I found it a bit disorienting to use your API. Please do not take this personally. This is only a matter of taste and personal preference. It doesn't judge your API by any neutral standard. It's just like a tea drinker prefers tea over coffee. – Water Cooler v2 May 21 '14 at 18:57
  • Thanks for the feedback. Feel free to open a new issue in our issue tracker - https://code.google.com/p/google-api-dotnet-client/issues/list and further explain. In my opinion those names should be easy to understand after reading the Google documentation of OAuth 2.0 and the OAuth 2.0 protocol. Any specific suggestion how to improve the documentation? – peleyal May 21 '14 at 18:58
  • 3) We all use language differently. Similarly, even when programming, we gravitate towards a habitual usage of idiom. I found your idiomatic expression different from mine. For e.g. you have nested classes for initializing outer classes in the case of, say, `GoogleAuthorizationCodeFlow` and its abstract base class. Also, the inner classes called `Initializer`'s are also related by inheritance. That's just one instance where I would have expressed code differently. – Water Cooler v2 May 21 '14 at 18:59
  • I definitely not taking this personally. Your input is very useful! :) – peleyal May 21 '14 at 18:59
  • 4) Overall, I would have tended to express intention differently. – Water Cooler v2 May 21 '14 at 18:59
  • 5) Finally, if you look at the Facebook Dot Net Client API, it is very symmetrical to the OAuth implementation. In other words, if you were to look at their flow of code and the design of their methods, their design is very transparent and similar to what a developer would do if there was no client. For e.g. the first method you have to call in the Facebook API is something like `new FacebookClient().GetLoginUrl();`, which gives you the first URL that you need to redirect the user to, akin to our `https://accounts.google.com/o/oauth2/auth`. – Water Cooler v2 May 21 '14 at 19:02
  • contd... comparison with the Facebook Dot Net Client on the basis of symmetry with OAuth To this method, you send the URL of a callback and your app credentials. It gives you its authorization code as JSON, just like the Google API does. But from there on, you're either pretty much on your own to send raw HTTP requests or call other methods that are very symmetrical do what raw HTTP calls you would do. As against that, I found your API to be very unintuitive in terms of what was happening where. – Water Cooler v2 May 21 '14 at 19:03
  • Surely, Eyal. I'll put in my notes in your issue tracker and also make a few suggestions, which again, are not necessarily better, but more inclined towards my tastes, which have become very Microsoft-like, and more-real-world-oriented. As in, I look at encapsulation a bit differently. Where you used a nested class to initialize, I would have used either a lambda or a parameterized constructor. And I'm very hung up on names. I would have changed the names a lot. – Water Cooler v2 May 21 '14 at 19:11
  • One more thing I found was that most NuGet package pages have the same one-liner description, which does not precisely tell you what the package includes. In comparison, look at the NuGet package page for Microsoft.BCL. The description tells you *precisely* what is there in the library and what all it is capable of doing. https://www.nuget.org/packages/Microsoft.Bcl/1.1.8 – Water Cooler v2 May 21 '14 at 19:15
  • Peleyal the API you've produced is really nice, except that I can't use it in my projects since it's non signed assemblies (no strong name). – Nordes Nov 28 '14 at 09:08