Gigya Job Openings

socialize.facebookGraphOperation JS

Skip to end of metadata
Go to start of metadata

Description

 

A generic method for making calls to the Facebook Graph API. This method can be used for Graph operations such as publishing Graph actions to the user's Facebook timeline.

To publish Graph actions, you must first configure your app for Graph actions and submit it for approval.

Note: This method is also supported in our REST API. If you wish to execute this method from your server, please refer to

REST API > socialize.facebookGraphOperation.

 

Syntax

 

 

Parameters

The following table lists the available parameters:

RequiredNameTypeDescription
graphPathstringThe Graph operation path. This is the part of Facebook's Graph URL that defines the operation. For example:
methodstringDetermines the HTTP method to use: "GET", "POST" or "DELETE". The default is "GET".
graphParamsJSON Object

A JSON object containing parameters to be passed to the Graph operation. For example:

graphParams: {
  "recipe": "http://demo.gigya.com/recipe1.php",
  "place": "14576",
  "tags": "208576,507763995",
  "start_time": 1303502229,
  "end_time": 1303513029,
  "expires_in": 330
}
authTypestringDetermines whether the graph operation requires an access token or not. The supported values are:
  • none - no access token
  • userToken (default) - a user access token is required. User access tokens are the standard type for API calls; these are generated in the login flow when a user grants permissions to an app.
callbackfunction
A reference to a callback function. Gigya calls the specified function along with the results of the API method when the API method completes.
The callback function should be defined with the following signature: functionName(Response).
The "Response Object Data Members" table below provides specification of the data that is passed to the callback function.
cidstring
A string of maximum 100 characters length. The CID sets categories for transactions that can be used later for filtering reports generated by Gigya in the "Context ID" combo box. The CID allows you to associate the report information with your own internal data. For example, to identify a specific widget or page on your site/application. You should not define more than 100 different context IDs.

Note: This parameter overrides the value of the identical parameter in Global Conf (the global configuration object). If the parameter is not set for the method, the value from Global Conf is used.

contextobject
A developer-created object that is passed back unchanged to the application as one of the fields in the response object.
authRequiredBooleanDeprecated

 

Response Object Data Members

FieldTypeDescription
errorCode integer The result code of the operation. Code '0' indicates success, any other number indicates failure. For a complete list of error codes, see the Response Codes and Errors table.
errorMessage string A short textual description of an error associated with the errorCode for logging purposes.
callId string Unique identifier of the transaction, for debugging purposes.
context object The context object passed by the application as a parameter to the API method, or null if no context object has been passed.
graphResponseJSON ObjectAn object containing the response data of the Graph operation. The response is returned exactly as it is received from Facebook Graph API without translation by Gigya.

  

Code Sample

function printResponse(response) {  
    if ( response.errorCode == 0 ) { 
        // Get Facebook's response data
        alert("The ID of the new action" + response.graphResponse.id);
    }
    else {
        alert('Error :' + response.errorMessage);
    }
}

// create a new action in Graph API
var params = {
           graphPath: "/me/socializedemo:cook",
           graphParams: {"recipe": "http://demo.gigya.com/recipe1.php"},
           "method": "post",
           callback:printResponse
};

gigya.socialize.facebookGraphOperation(params);

Notes:

  • This sample is not meant to be fully functional code. For brevity's sake, only the code required for demonstrating the API call itself is presented.
  • To run the code on your own domain, add your Gigya API key to the gigya.js URL. A Gigya API key can be obtained on the Site Dashboard page on Gigya's website. Please make sure that the domain from which you are loading the page is the same domain name that you used for generating the API key.
  • In some cases it is necessary to connect/login the user to a provider ? prior to calling the API method. You can learn more in the Social Login guide.

 

Removing Previously Granted Permissions

It is possible to remove permissions that a user has previously agreed to, without interfering with the user's experience (they do not need to be aware of the removal). To remove permissions, you need to do the following via the Gigya WebSDK:

  • Remove the permission you no longer require from your apps configuration. This prevents the scope from ever being re-requested by the app.
  • Add an onLogin event handler to your site. This event handler should do 2 things:
    • Determine if the user logged in via Facebook (this Method only functions when the user is currently logged into your facebook app).
    • Determine if this method has been run on this particular user before, and if so, skip. You will need to set a flag in your site's Data schema after successfully removing the desired scope(s) from the user and then check for that flag here.
  • If the user needs to have their permission scopes pruned, run the following code to get their currently approved scopes:

    gigya.socialize.facebookGraphOperation({
    	"graphPath": "me/permissions",
    	"callback": function(re) {
    		// Here you are requesting the user's currently approved permissions
    		console.log(re); // do something
    	}
    });
  • The above request will return a response similar to the following, depending upon their current scopes:

    {
        "graphResponse": {
            "data": [{
                "permission": "email",
                "status": "granted"
            }, {
                "permission": "public_profile",
                "status": "granted"
            }, {
                "permission": "user_friends",
                "status": "granted"
            }]
        },
        "errorCode": 0,
        "callId": "4389b2e5a76142fea9ffd0a8970643f4",
        "time": "2018-07-23T10:57:31.354Z",
        "status": "OK",
        "errorMessage": "",
        "statusMessage": "",
        "requestParams": {
            "connectWithoutLoginBehavior": "loginExistingUser",
            "defaultRegScreenSet": "Default-RegistrationLogin",
            "defaultMobileRegScreenSet": "Default-RegistrationLogin",
            "sessionExpiration": 0,
            "rememberSessionExpiration": 0,
            "apiDomain": "us1.gigya.com",
            "enabledProviders": "*",
            "lang": "en",
            "customEventMap": {
                "eventMap": [{
                    "events": "*",
                    "args": [null]
                }]
            },
            "APIKey": "3_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX_GPpmETmODizZnnbSA_Fh68Fs_WE8Zh",
            "graphPath": "me/permissions"
        },
        "operation": "facebookGraphOperation"
    }
  • If the scope you no longer want to request is listed in the 'data' array of the 'graphResponse' object, run the following method, if there are multiple scopes to be removed, you will need to run this separately for each one.

    It is important to be sure that you are providing a scope in the URI of the DELETE request, otherwise the user will be completely deauthorized from your app and will be forced to re-approve your app as if they are logging into your site for the first time.

    gigya.socialize.facebookGraphOperation({
    	"method":"DELETE", // <-- This deauthorizes the permission listed in the next line
    	"graphPath": "me/permissions/user_friends", // <-- Where the last part of the URI is the name of the scope to remove, in this case 'user_friends'.
    	"callback": function(re) {
    		// Check the response (explained below)
    		console.log(re);
    	}
    });
  • Be sure the previous request was successful. The response will contain a 'success' property in the returned 'graphResponse' object; if this is true, you then will add the aforementioned flag to your Data schema for keeping track of users that have already had their scopes adjusted:

    	"graphResponse": {
            "success":true
        }
  • If it is necessary to check the user's new permissions, you can run the same method call as the initial one, above, to view the newly edited scopes.

    "graphResponse": {
            "data": [{
                "permission": "email",
                "status": "granted"
            }, {
                "permission": "public_profile",
                "status": "granted"
            }, {
                "permission": "user_friends",
                "status": "declined" // <-- user_friends is now Declined!
            }]
        }

For additional information on Facebook scope management, see https://developers.facebook.com/docs/facebook-login/permissions/requesting-and-revoking/