el-GRen-US
 
     
DNN Facebook Authentication Provider is broken after FB upgrade to API v2.4

DNN Facebook Authentication Provider is broken after FB upgrade to API v2.4

Αυγ 28 2015
Κοινοποίηστε το άρθρο στο:

DNN has excellent abilities on extending the way users and visitors can interact with your website and your content. One of these abilities is the support of authentication providers other than the embedded DNN which is based on the ASP.net membership model. The Facebook Authentication provider will enable a user to login and register via a Facebook account and it will populate the required fields of First Name, Last Name and e-mail automatically thus making the registration of new users trivial.

Fig.1 - DNN Authentication Providers extend functionality and enable single sign-in services.
If you are user host you need first install the Facebook authentication provider via host’s extension before have it available in your website’s extensions. If you are not user host you need to ask your host to install it for you. 
Fig.2 - Install Facebook Authentication provider in Host Extensions.

To utilize this ability you will need to create an app via Facebook developers page (https://developers.facebook.com/apps

Fig.3 - Facebook Developers page > My Apps, Add a New App.

and enable the authentication provider in website’s extensions by filling the APP ID and APP Secret keys both coming from your FB application.

Fig.4 - Update fields APP ID and APP Secret and enable the provider.

After that all visitors of your website will have the option to automatically register via Facebook’s login. 

This functionality was working great before the last update in Facebook’s API to v2.4. Facebook took the decision to use declarative fields for all nodes and edges explicitly (https://developers.facebook.com/docs/apps/changelog). Especially for the [me] Node if you call it via API v2.4 without the fields parameter you will only get the name and the id fields and not all the fields you got with previous versions. 

See the examples bellow using Facebook’s Graph API Explorer (https://developers.facebook.com/tools/explorer

API v2.3

Fig.5 - Facebook Graph API Explorer with v2.3 and no fields parameter. These values are used by the authentication provider in DNN.

API v2.4 

Fig.6 - Facebook Graph API Explorer with v2.4 and no fields parameter. This is breaking DNN's Facebook authentication.
Fig.7 - Facebook Graph API Explorer with v2.4 and fields parameter explicitly returning specific fields and their values.

As you can see in Fig.7 the only way now to get the needed values is to explicitly request them via fields parameter. There is an option of course to request your data via a GET command toward a specific API version (e.g. v2.3) but unfortunately does not work via OAuth authentication (tested in DNN as you will read later in this article) since these calls always revert to your APP API no matter what you specify in your GET request. 

This change is a show stopper for DNN’s Facebook authentication provider. 

Digging the source code of the provider (under Components\FacebookClient.cs) there is an assignment to property MeGraphEndpoint (in the class FacebookClient which is derived from base class OAuthClientBase) of the value: https://graph.facebook.com/me. 

public class FacebookClient : OAuthClientBase
    {
        #region Constructors

        public FacebookClient(int portalId, AuthMode mode) 
            : base(portalId, mode, "Facebook")
        {
            TokenEndpoint = new Uri("https://graph.facebook.com/oauth/access_token");
            TokenMethod = HttpMethod.GET;
            AuthorizationEndpoint = new Uri("https://graph.facebook.com/oauth/authorize");
            MeGraphEndpoint = new Uri("https://graph.facebook.com/me");

            Scope = "email";

            AuthTokenName = "FacebookUserToken";

            OAuthVersion = "2.0";

            LoadTokenCookie(String.Empty);
        }

This value is then used in the:

GetCurrentUser<tuserdata>()
method to return user data in a Json formatted reply that using the Deserialize method will return as Datamembers the needed values. 

 public virtual TUserData GetCurrentUser<tuserdata>() where TUserData : UserData
        {
            LoadTokenCookie(String.Empty);

            if (!IsCurrentUserAuthorized())
            {
                return null;
            }

            string responseText = (OAuthVersion == "1.0")
                ? ExecuteAuthorizedRequest(HttpMethod.GET, MeGraphEndpoint) 
                : ExecuteWebRequest(HttpMethod.GET, new Uri(MeGraphEndpoint + "?" + "access_token=" + AuthToken), null, String.Empty);
            var user = Json.Deserialize<tuserdata>(responseText);
            return user;
        }

As you can easily identify the ExecuteWebRequest method will use the MeGraphEndpoint property value with the access_token parameter to get the data from the authentication service. Since this is not constructed in the FacebookClient class but inside the OAuthClientBase class it cannot have any parameters added to it except the access_token parameter. That is a show stopper and it will not allow to request the data as Facebook’s new API declares. I have tried to use the value of https://graph.facebook.com/v2.3/me as a temporary fix but it is not working either and the possible reason is that when you create your application in Facebook it will default to the latest API version and thus any call via OAuth reverts to this API. The only way to make it work is to have an application created in the past with previous API and use it for the authentication. I have reported this issue to DNN’s Bug Tracker (https://dnntracker.atlassian.net/browse/DNN-7446) and I will wait for their response since I don’t want to make any changes in the OAuthClientBase, a part of DNN’s core. 

Another option is to create an override version of the

GetCurrentUser<tuserdata>()
 and I will do that in a future article later this year. 

Thanks for reading and as always any comments or questions are most welcome.

Best,
Spyros

Spyros Samartzis
Σχετικά με τον Spyros Samartzis
I love creating web applications using Microsoft technologies and open source platforms.
My moto is "I work and enjoy technology every day!"
Συνολικά: 2 Σχόλιο(α)
Spyros Samartzis
Spyros Samartzis  This issue is now resolved due to the work of Behnam Emamian. The change was made in the base class (as I proposed) and a new property was added to resolve the issue. Behnam added the property to the FacebookClient[.]cs and the fix is done. Please check all comments in DNN’s Bug Tracker https://dnntracker.atlassian.net/browse/DNN-7446 The open source community did the trick again!
·
intelequia.com
  Pingback from intelequia.com

DNN 7.4.1 versus Facebook API v2.4
·
Πρέπει να είστε μέλος στο website ώστε να μπορείτε να σχολιάσετε. Παρακαλώ εγγραφείτε εδώ
Top