If the component matches one of the following Social Network sites, also defined in config.json, we will interpret the request as an Oauth request.
Google_provider, default google Facebook_provider, default facebook Twitter_provider, default twitter Linkedin_provider, default linkedin
Here is the list of steps you should be proceed to set up an OAuth issuer.
Step 1, Provider’s Parameters
You need to setup the Oauth service at provider’s side. Please consult their developments for details. After it is done, you should receive a few relevant parameters. Put them in Provider_pars of the issuer.
Step 2, Build Issuer
For OAuth1 you should always use “Credential” : [“oauth_token”, “oauth_verifier”] , and for OAuth2, “Credential”: [“code”, “error”].
So the issuers in config.json will look like:
"Issuers": {
"facebook": {
"Provider_pars": {
"client_id": "1111111111",
"client_secret": "xxxxxxxx"
},
"Credential": ["code", "error"],
"In_pars": ["id", "first_name", "last_name", "client_id", "access_token", "expires"],
"Out_pars": array,
"Sql": string
},
"google": {
"Provider_pars": {
"client_id": "111111-xxxxxxxx.apps.googleusercontent.com",
"client_secret": "xxxxxxxxx"
},
"Credential" : ["code", "error"],
"In_pars": ["id", "given_name", "family_name", "client_id", "access_token", "expires_in"],
"Out_pars": array,
"Sql": string
},
"twitter": {
"Provider_pars": {
"oauth_consumer_key": "xxxxxxxxxxx",
"oauth_consumer_secret": "xxxxxxxx",
"owner_id" : "11111111"
},
"Credential" : ["oauth_token", "oauth_verifier"],
"In_pars" : ["user_id", "screen_name", "oauth_token", "oauth_token_secret", "x_auth_expires"],
"Out_pars": array,
"Sql": string
},
"linkedin": {
"Provider_pars" : {
"oauth_consumer_key": "xxxxxxx',
"oauth_consumer_secret": "xxxxxxxxxxx',
"oauth_endpoint": "http://api.linkedin.com/v1/people/~:(id,first-name,last-name)"
},
"Credential" : ["oauth_token", "oauth_verifier"],
"in_pars": ["id", "firstName", "lastName", "oauth_token", "oauth_token_secret", "oauth_authorization_expires_in", "oauth_expires_in"],
"Out_pars": array,
"Sql": string
}
}
In the above setup, you are assumed to collect the minimal sets of user information so as to keep the best privacy. To collect more user information, you can specify them in scope or end_point.
Step 3: Create Sql
When a visitor hits an OAuth URL, she will be redirected to the provider’s site. After her successful login and authorization, she will eventually land on your website again with variables defined in In_pars.
At this moment, Genelet will run the stored procedure Sql , to query data, to execute transactions and finally to generate a set of output variables defined in Out_pars. What exactly Sql should be depends on your data model in the project.
Attributes, which defines variables stored in the login cookie, should be a subset of Out_pars. If the later is not explicitly defined, then is default to Attributes.
Step 4: Debugging and Errors
Since you are not able to code any program for the relatively sophisticated OAuth process, please take a look at the debugging messages. If everything goes correctly, Sql will run which is under your control. Like the db issuer, you should return an empty value for the first element in Attributes in case you want to deny this OAuth attempt.
Step 5: Issuing Ticket
After the Attribute variables are generated, the same step as that in the db issuer will be proceeded. Specifically, a login cookie will be saved into the browser and used for followup visits at the gate until the expiration or invalidation.