Google_Service_Oauth2 get user info

I am unable of retrieving authenticated user information through Google_Service_Oauth2. After authentication processes i am able to execute the following method:

$user = $oauth2->userinfo->get();

But when I print user fields by calling getEmail, getGiven_name, getFamily_name and so on, these fields are in blank except for getId. User Id is ok, so the authentication process is correct, but basic profile information is in blank.

I saw that this get method accepts an array of optional parameters, and I have tried to add email, or other fields but it does not work.

With the old 0.6.x library I was able to extract these fields without problems.

Any hint?

I see the same behaviour and so far narrowed it down to the Oauth service's scopes not being properly registered with Google_Client. This should be done by the Google_Client::prepareScopes() which is called from Google_Client::createAuthUrl().

In the old library there was a Google_Client::prepareService, which was called from Google_Client::createAuthUrl() as well as Google_Client::authenticate().

I'm still digging this, but there's a workaround to this:
you can call Google_Client->setScopes('') before a call to createAuthUrl() to explicitly set the scopes.
This way you will be able to get the info.

Ok, I have set the following scopes declared by default in OAuth2 before creating the createAuthUrl an now its working fine:

$client->setScopes(array(
"https://www.googleapis.com/auth/plus.login",
"https://www.googleapis.com/auth/userinfo.email",
"https://www.googleapis.com/auth/userinfo.profile",
"https://www.googleapis.com/auth/plus.me"
));

So there is a bug by automatically setting the scopes in client when adding an OAuth2 service to client. By default this request requires more user information like plus circles and other google plus information, what does not happen with previous OAuth2 version.

I found the problem, I have proposed a pull request in:

#7

It was a little bug when adding serviceScopes to requestedScopes...

@alvarolb

@alvarolb , you beat me to it ^_^; I was about to send exactly the same pull request myself...

@nyaaao

@nyaaao I fix that thanks to your help =)
I dont know how this bug is present in this version... there are 51 calls to addService with availableScopes! Some of them contains only one scope, so there is no problem, but many of them contains more than one or 0! A little bug that affects all services...

This was actually somewhat intentional, as the scopes are somewhat inconsistently documented - we considered not doing any automatic scope retrieval because it regularly doesn't deliver what is expected. What was being done in 0.6 was guessing at the scope based on service name, which didn't aways work either.

For example, the userinfo APIs do document those four scopes, but there is both redundancy and over-scoping in there. Requesting all possible scopes would definitely make the calls work, but would also lead to consent dialogs with more scopes than are really required.

My inclination is to go back to removing automatic scope selection entirely, as, for this API in particular, there is no decent single scope choice. You probably want userinfo.email and userinfo.profile, but not the plus scopes, for example. For most of the other APIs I suspect selecting the shortest scope will give a sane default, but that would give plus.me in this case, which would only return the user ID.

I now understand the problem. In this case I would propose a simple approach:

In order to keep the code as is I would add a method in Google_Service called 'setRequestedScopes' with an array of strings. This method can check that the given requested scopes are within initialized available scopes to avoid user submitting invalid scopes for the given service. Also, as the client is yet initialized in Google_Service by its child class, automatically call a method on Google_Client called setServiceScopes filing the $requestedScopes similar to addService, maybe with the same parameters. Then, in prepareScopes iterate over requestedScopes instead of available availableScopes, so in this case are only filled the requested scopes. In this case I do not see necessary the addService method (and availableScopes) in Google_Client as it would contain redundant information and only is used, apparently, in prepareScopes.

So in this way each service will contain it set of availableScopes and the client a set of requestedScopes for each added service as the user requirements. This would require documentation about scopes for each service...

@alvarolb

Hmm, I'm not sure we should be automatically selecting scopes at all. The simplest solution from a library point of view would be to remove the defaulting of any scopes, and require that they are manually set. This is how several of the other client libraries work. That would also remove the need to do addService.

The previous version of the client library basically guessed, by setting a scope based on the name of the service. This worked in some cases, not in others, and caused too much access in others.

The current strategy of selecting just the first scope clearly has issues (e.g. the most generic YouTube scope is in the middle of the bunch), but requesting all scopes wouldn't fit either. @alvarolb regarding your suggestion, if the user is going to the trouble to request setRequestedScopes, then they may as well do that on the client directly. How about:

No scopes are requested automatically
We add a new addScope method to the client which will add the scope and automatically supress duplicates

To make life easier we could look at adding friendly constant names for scopes (e.g. Google_Service_YouTube::SCOPE_YOUTUBE_READONLY) though writing it out now it doesn't look much shorter! We could also check that there are services connected which provide the scopes, to try and avoid typo'd scopes.

We could also make this a configurable behaviour. Overall though, I think requiring the scope to be specified is the only really sustainable choice.

I agree with Ian, requiring the scope to be specified is the only really sustainable choice.

I also agree, there should be some way of selecting desired scopes, so no default scopes are selected by default.

If we're removing the Google_Client->addService(), can we do something about the service initialization, i.e. the restriction when initializing with an authenticated Google_Client? Currently we may obtain the access token from somewhere else, skip the Google_Client->authenticate() part and use Google_Client->setAccessToken() right away, effectively bypassing the restriction and getting a 401: Unauthorized Request in the face if the token did not grant the access to the API. If the developer would be responsible for getting the right token and there is nothing else in the library that depends on this, we may safely remove this check altogether.

Closing this one for now - there's a bit of tidy up pending the next batch of template changes, but the move to manually specifying scopes is in. As for the next template change we'll have some friendlier constant names that can be references for the scopes as well (though they're attached to our current long class names, so the benefit is cognitive rather than finger mileage!).

removes auth library caching

Merge pull request googleapis#6 from tbetbetbe/php-auth-add-oauth2-base

I can print the user information if i put the below code on my localhost(Using Xampp Server)

$oAuth = new Google_Service_Oauth2($client);
$userData=$oAuth->userinfo_v2_me->get();
echo "<pre>";
print_r($userData);
echo "</pre>";

But can not print the user details when i have moved my code from local to live server.

I don't know what is the issue.

i am not getting name for some user please help

Fix: Uncaught RuntimeException: Unable to read from stream

Navigation Menu

Repository navigation

Google_Service_Oauth2 get user info #6

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Google_Service_Oauth2 get user info #6

Description

Activity

nyaaao commented on Nov 28, 2013

alvarolb commented on Nov 28, 2013

alvarolb commented on Nov 28, 2013

nyaaao commented on Nov 28, 2013

alvarolb commented on Nov 28, 2013

ianbarber commented on Nov 28, 2013

alvarolb commented on Nov 28, 2013

ianbarber commented on Dec 10, 2013

silvolu commented on Dec 10, 2013

alvarolb commented on Dec 10, 2013

nyaaao commented on Dec 10, 2013

ianbarber commented on Dec 23, 2013

appadmindelhi commented on Jan 3, 2018

bichitra12 commented on Sep 15, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions