-
Notifications
You must be signed in to change notification settings - Fork 3
Authentication Workflow
#Authentication Workflow The following section will outline the authentication workflow used on both the client and server side of beLocal and will also provide information on how to extend it if necessary.
Client side authentication is handled using the OAuth.io library. Currently, only Facebook authentication is enabled through use of the following code snippet in navbar.js
OAuth.popup('facebook', {cache : true, authorize: {'scope':'email'}})
It is important to note the use of the “authorize” parameter in this function call. This is where all extra permissions for Facebook (such as requesting email, user likes, friend lists, etc.) is handled. Even if these values are to be used exclusively on the server-side, they must be specified here so that the proper permissions are granted during the initial login process. After authenticating with Facebook, an authentication token is passed back from Facebook to the client. This token is then passed to the server in an HTTP POST message to the REST endpoint /login/facebook.
Twitter authentication occurs in the same way as Facebook authentication in seller.js
OAuth.popup('twitter', {cache : true})
New Tweets can be composed programmatically using the following code:
twitter.post({url: '/1.1/statuses/update.json' + '?status=' + escape($scope.twitterString + $scope.hashtag)});
It is important to note that certain special characters (such as exclamation marks) are not allowed to be posted to Twitter in this manner. Several fixes have been investigated (including encoding special characters), but Twitter's API still returns an error code 32.
On the server side, a second authentication stage with Facebook occurs via the use of Python Social Auth. The token sent from the client is repackaged and sent to Facebook again in order to retrieve basic user information such as name and email. If the second authentication loop is successful, Python Social Auth will create a django.contrib.auth.models User object with the data coming back from Facebook, and will also create a Django REST Framework Authentication Token object for this user. This will allow the user to make requests to endpoints on our server that are protected with
authentication_classes = (TokenAuthentication,) permission_classes = (IsAuthenticated,)
If this process is successful, the user information obtained from Facebook, as well as the newly created authentication token, will be passed back to the client side in a JSON object. The contents of this object will then be stored in a cookie on the client to “cache” the user's authentication token and profile information.
There is currently no server-side authentication for Twitter. When a vendor successfully authenticates with Twitter on the client side, we make a PATCH call to the endpoint /vendor to update the vendor's Twitter URL on the server.