stevenmaguire
commented
5 years ago LinkedIn changed their API in such a way that the email is only available via a second API call and with an access token that has the appropriate scopes.
This is a breaking change for BC which is why it was given a new major release bump from 4 to 5.
One of the other users of this package suggested an idea of some configuration that may help retrieve the email address via two API calls behind the scenes but I did not accept that suggestion because I feel it obfuscates what's actually happening and introduced a new configuration step that I feel only further confuses the behavior of this package and its relationship with the API.
Of course a workaround can be added when LinkedIn provider is detected, but this defeats the purpose of using this library, expecting to return data in a common format.
I agree with this position 100% and as a maintainer of dozens of OAuth2 packages, I can tell you this is a reality when upstream APIs turn into edge cases. Once this happens there is no reasonable expectation that the package API remain uniform as package-by-package code changes (deviations) are going to be required.
In an effort to help explain that decision, I will share what was proposed:
$provider = new League\OAuth2\Client\Provider\LinkedIn([
'clientId' => '{linkedin-client-id}',
'clientSecret' => '{linkedin-client-secret}',
'redirectUri' => 'https://example.com/callback-url',
// Set this boolean to true if you want to provider to attempt to fetch
// the email address as a second call on getResourceOwner($token)
'getEmail' => false,
]);
$options = [
// The scope MUST include r_emailaddress or the request for the
// email address will fail because the access token does not have
// sufficient permissions.
'scope' => ['r_liteprofile', 'r_emailaddress']
];
$authorizationUrl = $provider->getAuthorizationUrl($options);
// obtain $token, etc.
$user = $provider->getResourceOwner($token);1) If the provider getEmail config setting (which is different from the common oauth2-client API) is set to true but the r_emailaddress scope is not present, getEmail() will return null and/or the flow would break because that second API request failed and an HTTP exception is thrown. (more on this in a moment)
2) If the provider getEmail config setting is set to false and the r_emailaddress scope is present, getEmail() will return null because the second API request is not made.
In both instances, we can surely expect to receive issues here on Github about the package being "broken" and the workaround is to make some code changes that are non-standard across the oauth2-client eco-system.
In any event, the moment this package introduces "non-standard" API changes it does need to be handled differently. And if that is the case, my preference is that the provider offer a second method, which takes an access token as a parameter, to attempt to fetch the email address via the second LinkedIn API call so that you can handle the response independently.
If we looked at use case 1 above you could say: "Well, that's ok, let's still attempt to make the second API call for the email address and we'll swallow the exception and set the resource owner email to null". That sounds like a fine solution until someone wants to know why the email is still missing or the LinkedIn API responds with some funny, unexpected response. We could then say: "Well then, let's let it throw an exception and we'll handle it." That is exactly the outcome of the new design pattern except you have more control and granularity over when you fetch resource owner details.
$provider = new League\OAuth2\Client\Provider\LinkedIn([
'clientId' => '{linkedin-client-id}',
'clientSecret' => '{linkedin-client-secret}',
'redirectUri' => 'https://example.com/callback-url',
]);
$options = [
'scope' => ['r_liteprofile', 'r_emailaddress']
];
$authorizationUrl = $provider->getAuthorizationUrl($options);
// obtain $token, etc.
$user = $provider->getResourceOwner($token);
$email = $provider->getResourceOwnerEmail($token);With all that being said, I did not think the previously proposed solution was effective and I am open to exploring new ideas and am inclined to accept suggestions that keep the inner workings of the package simple and predictable (easy to troubleshoot).
AndreiIgna
OJezu
jahrralf
Yamakasi
Hi,
I saw the new update is using only v2 API, which is great, and removes the
getEmail()method 😕Some integrations use the League OAuth2 client precisely because it returns OAuth data in a common format across providers, making it easier to work with different OAuth providers.
This WordPress plugin https://github.com/LayeredStudio/quick-login (amongst others) relies on a provider's ResourceOwner to have the
getEmail()method. Of course a workaround can be added when LinkedIn provider is detected, but this defeats the purpose of using this library, expecting to return data in a common format.Is there a way to add the email data again in ResourceOwner?
emailis a piece of information related to the OAuth user (ResourceOwner in this case) and not about the provider.If others would have the same need for the email field, maybe we can come with some ideas and make a PR for this.