Learn how to write code for authentication flow.
- [Instructor] Now that we've got the credentials necessary to make calls to Fitbit, we're ready to add some more functionality to the code we've got. Let's add the auth flow in the application so we can make authenticated calls to the platform and retrieve some data. The code has been pared down for us here as we're going to implement new functionality. First, let's set up some variables at the top of the code to add Fitbit interaction. So first, we're going to need to, obviously, import the library. So var fitbit = require('fitbit-node'); The next thing we're going to need to do is set up a client.
So the client is going to need the token information from the developer portal, so we can copy and paste it into the code, so let's set up the client here. client = new fitbit, and we're going to need to get two pieces of information from that developer portal. So let's go ahead and get that now. Open up your browser to that screen. The first piece of information you need is the OAuth 2.0 Client ID, so grab that, put that in the first string, and the second piece of information we need is the Client Secret, so go ahead and grab that, and paste it.
And we got the client all set up. So the next thing we need to do is set up a redirect URI, and the redirect URI is going to tell Fitbit where to send the request back, and it needs to match the value input in the application setup. So var redirect_uri is, http://localhost:8080/Fitbit_oauth_callback. You'll get an error if this doesn't match, when the user is redirected.
So the last thing we need to do is the scope, and the scope is going to tell Fitbit exactly which pieces of data the application wants to access, so the user can be given that information during the authorization step. So var scope is activity profile, those are the two pieces of information that we want to use. So we're going to create a couple of routes to start with here. The first one is going to redirect to the Fitbit authentication flow, and the second one is going to do the callback from their system.
So let's start out with a new route, copy the route, don't forget the comma, and the path here is going to be /fitbit. Now, for the handler, we're going to want to use the fitbit-node functionality, to redirect the user to the fitbit-auth system, while sending some important information along. All this endpoint is going to do is redirect the browser to the authentication URL for Fitbit. The fitbit-node client has a getAuthorizeUrl function to generate the URL we need in order to start the authentication dance, and we'll use the scope set in the variables above to indicate exactly what permissions are wanted here.
So we're going to reply, instead of replying with a string, we're going to reply it with a redirect, and we're going to redirect to client.getAuthorizeUrl, and the things that we need to pass in here are the scope, and the redirect_uri, and so that should take care of the Fitbit endpoint. Once the permission is given, the user is going to be redirected back to another route, so we'll build that one next. Copy and paste the route we just created.
And this one's going to be fitbit_oauth_callback. In the handler for this route, we'll be pulling the information from the code query parameter returned by Fitbit, and we'll request an access token to use for user calls. The fitbit-node library uses promises, which we'll extend later for our system, but for now, we'll use the promise to grab the profile for the user so we can test out the functionality. This section demonstrates another piece of the request which can be accessed, namely the query parameters.
These can be accessed with request.query. So first, let's use the client to call getAccessToken, and get ourselves an access token. getAccessToken(request.query.code, redirect_uri). Then, with the result of that, what we're going to want to do is do a client.get on the profile.json, and in order to make that call, we're going to need the access token we just got back from the getAccessToken call.
So it's result.access_token, and once we've done that, getting the profile, then(function(profile)), so we've retrieved the profile from Fitbit, now we can reply with the profile, back to the browser. So that finishes the setup for the authentication dance. Let's go ahead and run it and see what happens.
Open up your browser, localhost:8080/fitbit. Okay, so we're not using HTTPS, which is not surprising, we know that. Lynda Sample Application by my company would like the ability to access and write the following data. Notice that we ask for activity and profile, so I'm telling the user that we want the activity and profile. And I'm going to click Allow. Okay, great. So what happened here is it made the call, back to Fitbit, it did the authorization dance, I got the authorization, and this is all the information about my user, this is the profile information.
It's not pretty, it's a JSON object, we can do all sorts of great things with it, but you can see that the authentication server is working. So to summarize what's happening again, the /fitbit endpoint redirects the browser to Fitbit, providing credential information to indicate which application's requesting permission, and exactly what scope is requested, along with a redirect URL so that Fitbit knows where to send the user once they've given permission. The user is informed about the application requesting permission, and exactly what type of data it wants.
- Setting up the development environment
- Consuming an API using HTTPie
- Inspecting Mongo data
- Updating the server for MongoDB read functionality
- Setting up application endpoints
- Implementing user endpoints, progress endpoints, and promises