You can think of a strategy as a middleware for Passport.

There's a general process you need to go through when setting it up.

First, you need to install the Strategy through NPM.

Second, register your application with the provider.

In our case, it's Get Up and Facebook.

This is where you'll get your ID in secret,

in other words, your application username and password.

Third, configure your Passport Strategy or

Passport Middleware with the ideal key and secret.

Finally, set up the routes for the provider.

First, let's install the Passport Strategy for GitHub with the NPM Save Flag.

Once Passport GitHub is installed, we need to head over to GitHub.

Go to your Account Settings.

And, on the left-hand side, there's OAuth applications.

Here you'll see all the applications that use OAuth that you've ever authorized.

Notice how you can revoke an application's access to your information at

any time without involving a third party.

At the top of the page, there is Developer applications.

Here is where you register your application.

Enter in the application name here and the URL for the application.

Generally, you would have multiple OAuth apps, one for development,

one for staging, and one for production.

Since this is for development,

I'm going to add my development URL of localhost3000 here.

This is generally the homepage of the site.

Then, the call back URL is the route where your application will handle the return

call from the OAuth provider containing the profile information.

Let's use our development URL /auth/github/return,

submit the form, and

you find yourself presented with the client ID and client secret.

We'll use this in a moment, keep your browser window open here.

Let's go back to our app.js file, and

just after we require everything we can include passport use.

Like Express, passport has a use method to use passport specific

middleware called strategies.

Just under where we require passport, let's require the GitHub strategy.

We're using the variable name GitHubStrategy because

we're using another strategy later on, and we don't want our variables to clash.

We need to configure our GitHubStrategy.

In the passport.use method, let's initialize the GitHubStrategy.

The passport strategy takes two arguments, set of options and a callback.

The options required are client's ID which is a string,

a clientSecret, which is a string also,

and then the callback URL.

This is the same one from earlier

Be sure that your URLs are the same one we used when

setting up our application GitHub.

For example, if you use 1.7.0.0.1 rather than local host, you'll get an error.

I've left the clientID and clientSecret blank on purpose.

You don't want to actually put these values in here for security and

maintenance reasons.

Firstly, you don't want to submit sensitive information like this

into version control.

You could end up uploading your credentials to a repository, potentially

exposing the information to others, who could use them to spoof your application.

Secondly, you don't want your development credentials deployed to staging

and production.

You don't want to mix up your development and

staging uses with your actual user base.

Also if the developer leaves the company you work for

even favorably, you want to be able to revoke that development environment

without affecting your production uses.

It's just good practice to separate IDs and secrets for all environments.

iI's save potential future headaches.

To get around this will use environmental variables.

We'll use GitHub clients

ID And

GITHUB_CLIENT_SECRET, For the secret.

We can pass them in as arguments or set them before we run the node application.

I'll show you how to do that shortly.

The callback function takes an accessToken, a refreshToken,

a profile JSON object, and a callback, done.

This is an ideal place to find or create a user document in the database.

Mongoose has a method called FindOneAndUpdate,

which takes a filter criteria And updates object.

Some options, and a call back.

The mongoose model finds a single entry based on search criteria.

The search criteria in our case, is the user's email address.

We can access the email from a list of emails returned by the profile

object from the OAuth callback.

We may use different providers OAuth functionality, GitHub and

Facebook and Twitter for example Is always good when setting up a new

provider to inspect the profile object.

So that you're sure that you're getting all the information you expect and

it's in the correct format.

If we find the object we should update it with the latest information from

the social network.

The display name property on the profile object is the user's name.

Then the email address and The photo.

We can get the first image from a set of photos.

[SOUND] The display name may not be

available from the OLF provider.

We can set to be the providers username instead

You may be asking what if this is the first time the user is using the site

there is no use a model to find an update.

What can we do?

We can use the opt set option that will insert the model if it doesn't exist or

if it does.

[SOUND] When it's called on at some point to hand

control back to passport and eventually back to express so

it can execute the next piece of middleware Like before,

when we found a user, we can pass done to the FindOneAndUpdate method.

If there's an error from the upset process,

that method will pass in an error to done as the first document.

If a document is found, it'll be passed as the second argument.

The second argument passed to the 'didn't call back' by the find one and

update method, is the user model

that is added to the request object which will be available for all routes.

Now depending on an individual's user privacy settings,

their e-mail addresses may not be available.

If it's not available.

We need to pass an error to the done callback.

Let's create an error saying your

email privacy settings prevent

you from Signing into Bookworm.

Then we can pass this error into the done callback.

And nothing as the second parameter.

We'll create our authorization routes in a separate file,

auth.JS in the routes' directory, in just a minute.

But before we do that, let's wire up the routes in the app JS file.

Underneath the index.JS file containing all the get routes for the app,

let's create an auth route.

Then we can use this auth route down here next to the other get routes.

Awesome!

Now let's create the auth.js file in the routes folder.

Let's also require express and express.Router at the top of the file.

Let's also include passport.

Now we can create our first login route.

Instead of creating our own rout handler.

We'll use Passport's authentication handler instead.

We need to include which strategy we use too, github.

Then we need to implement the call back URL return.

But this time we need to include an options object.

With the failure redirect key.

This is the path you want to send users if they don't authorize your application or

there was some other failure.

Maybe a stand alone login page would present an error to them.

In this case, we're just sending them back to the home page.

Finally, we write our own handler with a request and response.

You can do anything here for example.

You could log the time the user logs in for analytics and security reasons.

We can just simply redirect to the profile page.

Now we have the logging complete.

We need a walking out route,

The Passport middleware not only adds the user property to the request objects,

it also adds a logout method.

When you call it, it logs the user out.

Then we can redirect the user to the homepage.

Don't forget to export the router.

Before we start our application before to start the MongoDB server.

Now to start the application with environment variables on a Mac and

Linux, you can include environment variables immediately proceeding

the application start command Check the teachers notes on how to do it in Windows.

Now that the application is running, let's visit it in our web browser.

Click on Log In.

With GitHub.

Authorize the application, and bam, we're signed in