In the last section we finished wiring up our authentication flow by enabling cookies inside of our
application and then essentially telling passport to use cookies to manage our authentication.
So at this point you might be sitting there thinking OK like we are authenticated I guess but what does
that really get us.
Like what do we care now.
Why is this relevant at all.
So let's look at a quick diagram that's going to tell us exactly what the end result of all this authentication
stuff is.
And then from that diagram We'll also get a better sense of how we will test out our authentication
flow to make sure that it is working.
So I to flip over to a diagram really quick.
OK.
So this is essentially the flow that is going to occur any single time a user makes a request to our
application after having gone through the waterflow.
So some request is going to come in from the browser.
So we take that request.
That request is going to be passed to that cookie session thing which is going to automatically extract
all the data out of that cookie and it will encrypt the data that exists inside of there that data is
then passed on to passports which pulls that user ID out of the cookie data.
The idea is then passed on to our serialise user function where we are currently taking that ID and
turning it into a user model instance and then the end result of all this like the end product.
The thing that we were going through all this work forward to just make this happen.
The very end result is that the user model instance that we returned from DC relies user is added to
the request object as rec dot user.
And remember weve seen the word rack a couple of times inside of our application rack is the short for
the request object that is passed into any express route handler.
So after this entire automated process wraps up for every request that comes in that request that just
got modified with recked user is then sent on to whatever route handler is supposed to deal with that
request.
So in order to really test this thing out we are going to add a new route handler inside of our application
whose sole purpose is to kind of inspect this redcoat user property.
We'll look at that user property and if our user model exists on that thing that means that authentication
must be working inside Iraq.
OK.
So that's how we're going to test this.
So let's define a new route handler.
I'm going to find my routes throughout start G-S file.
So here is where we have our two handlers right now for handling the process underneath.
Both of these.
I'm going to add a third handler so we'll say whenever someone makes a get request to our app and we'll
give it the route of slash API slash current user and I'm totally making up this route right here by
the way.
Remember we can define routes that are called anything we want.
I'm just kind of thinking about our application the future.
I'm assuming that we might want to have some API route that returns whoever's currently logged into
the application.
Now the second argument we pass our arrow function though will be automatically called Whenever someone
makes a request to this route right here.
Remember that the arguments for this function are the wreck and rez objects.
Recked represents the incoming request rez represents the outgoing response.
So all we're going to do here.
We're going to keep it nice and easy.
We're going to just immediately send back.
Redstart send.
So just make an immediate response.
And we want to send back rec dot user so this will test to make sure that someone who has already gone
to the flow and in theory logged into our application can now you know hey get access to the user.
That's pretty much it.
OK.
Enough talking.
I've spoken enough so far about authentication.
It's time to just test this thing out.
So I get it changed back over to my server.
I going to verify that it is running and I do not have any errors outside of those two deprecation warnings.
So everything looks good.
I will then change back over to my browser.
Now we have to go through the authentication flow one more time because remember we only just added
on all this additional logic around cookies.
So we have to go through the flow one more time to get our cookies set up and all that kind of jazz.
So open up a new tab or go to a local host Colan 5000 slash off slash Google.
And remember we haven't really added any code yet to really resolve this response.
We will fix that up in just a little bit.
But essentially after we visit this route we're still going to kind of like see an air or have the requests
just hang.
Or something like that.
So we'll visit this route.
So that should kick us over to Google.
It should initialize our cookie it should kick our user ID into the cookie and then return that cookie
to our browser.
So in theory I now have a cookie tied to our application that identifies me as a very particular user.
Now again you see an era peer that's totally fine.
Totally fine.
It's just because we are not properly handling this request but we will fix that up in just a second.
So now I'm considered to be logged in and authenticated to our application.
So the last step to test this out and then open up a second tab and navigate to localhost.
5000 slash API slash current user when I navigate to that route we will go through this flow right here.
The request will come in the cookie session that we just wired up will extract all the data other cookie
passport pulls out the ID that ID is passed to the DC your lies user function that we wrote which turns
the ID into a user and then that user is added to our request object as recked user and the request
goes onto the handler.
So let's give this a shot and hit enter and we get a response of our user model exactly as it exists
inside of our application.
So heres my user ID Here's my google profile ID and then the underscore underscore the property is something
that is maintained by mongoose and its not something we have to worry about.
So thats it.
It works.
Hooray.
I don't know what to say.
That's a lot of work to make authentication happen.
Right now we're not even done.
We don't have the ability to log out yet.
So yes authentication is a lot of work.
There is a lot that goes into it but I hope I pray that now you have a much better sense of what is
going on behind the scenes with all this passport stuff.
And I hope you have a much more solid understanding of how a lot works inside of modern applications.
So we've now got this Google strategy put together right here.
You can go and install a Facebook strategy or a Linked-In or a good hub or any other strategy you want
to use and wire it up to our application in a very similar way to what we just did right here.
Honestly go install the strategy define this callback function and that is all you have to do.
Well there's one more thing you've got to set up these off Google handlers but that's pretty much it.
So once you do that stuff you can add in Facebook authentication linked in get hub all these different
providers with the exact same techniques that we've now established so far in this course.
So I know it has been painful going through this.
I know it has been very long but we have a fantastic new skill now and we really know how to handle
authentication in our application.
Okay so enough of the pep talk we still have obviously a tremendous amount of stuff to do inside of
our application to build this final app that we're trying to get working.
So I want to continue in the next section.
The first thing we're going to do is we're going to add one little piece of logic to allow us to log
out of our application and that will allow us to really test the entire authentication flow from start
to finish.
And then after we talk about how to integrate log out we'll take a break.
We'll come back in the section after that and we'll do that optional discussion about exactly what is
going on with some of this kooky stuff over here.
OK.
So let's get to it.