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.
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.
To utilize this ability you will need to create an app via Facebook developers page (https://developers.facebook.com/apps)
and enable the authentication provider in website’s extensions by filling the APP ID and APP Secret keys both coming from your FB application.
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)
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
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";
This value is then used in the:
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
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);
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
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.