Now that we understand about cookies and express sessions,
in this exercise, let's look at cookies in particular.
We will see how we can use the cookie-parser middleware
to set up and handle cookies within our express application.
Going back to our ConFusion Server Express application
that we have been working on so far,
you will notice at the top that the cookie-parser is
already included in our express application.
If you need to explicitly install cookie-parser,
you just need to type "npm install cookie-parser minus minus save."
But since our Express Generator has already included
the cookie-parser into our express application that we scaffolded out,
we don't need to do that step in this exercise.
So, you see that the cookie-parser is already included there,
and then if you scroll down,
you would see that in the code right below here,
you would see the cookie-parser has already been included into the middleware there.
Now, for this cookie-parser,
we will be using signed cookies in this exercise.
So, for this cookie-parser,
I'm going to supply a secret key as the parameter here.
The secret key could be any string there,
so I'm just going to supply a string like this, I'll say 12345-67890.
It doesn't have to be anything meaningful,
it's just a key that can be used by
our cookie-parser in order to encrypt
the information and sign the cookie that is sent from the server to the client.
So, once we set up our cookie-parser to handle signed cookies,
so then within the authorization itself,
so you see that we have the authorization that we have built in here.
Now, within the authorization,
what we're going to do is,
the first time that the user tries to access the server,
we will expect the user to authorize himself or herself.
Thereafter, we will set up the cookie on the client side from the server and
then subsequently the client doesn't have to
explicitly keep sending the basic authentication information.
Instead, the client will simply need to include the cookie in the outgoing request.
Since we are using signed cookies here, so,
when the incoming request comes in,
so we will handle that inside the authorization.
Now, you recall that we have already set up the authorization middleware here.
So, we're going to modify this authorization middleware to make use of
cookies instead of the authorization header.
So, what we will do here is that,
we'll say "console.log" and then we will,
"console.log(req.signedCookies)" so that we see what is actually
included in the signed cookie here.
Now, also after this,
what we will do is we'll say, "If (!req.signedCookies.user)".
User will be a property that we will set up
in the signed cookie as you will see a
little bit later how we will setup the signed cookie.
So, if the incoming request does not include the user field in the signed cookies,
and then that means that the user has not been authorized yet.
So in that case,
what we will do is expect the user to authenticate himself.
So, then, we will do all this part here.
So notice that we had already done this
earlier where we were handling the authentication header.
So we will take all this part,
all the way up to this "else" here and then include that inside here.
So essentially, what we are specifying here is that,
let me indent it.
As you see, I am very particular about my indentation
because that keeps the code more easier to read.
So inside this if,
so this is the closing point of the if of this one here.
So we are saying if the signed cookie doesn't contain the user property on it,
then we expect the user to authorize by including the authorization header.
So we'll look for the authorization header.
If the authorization header is not available,
then we will simply reject the user and prompt
the user to enter the username and password as we did in the previous exercise.
If the authorization header is included,
then we will process the authorization header just like we did before,
and if the user is an authorized user,
recall that we called the next to let the user proceed forward.
Now at this point,
what we will be doing is that we will say,
we will set up the cookie at this point.
So this is where we will use the res cookie here.
Notice that the cookie doesn't exist,
so we'll say "res.cookie."
As you can see, the res cookie itself takes the first value name string,
value string and options, cookie options.
Set the cookie name to value with the given options and the options are included here,
some options for the cookie here.
I'm going to simply use a few of the options here.
So we'll say, "res.cookie" and then I'm going to set up the cookie with the name user.
Now notice that this is the reason why I am
checking for the req.signedCookies.user up there.
So we'll say "res.cookie('user',)" and
the user field I will set it to 'admin' and
then I will set this up to be a signed cookie.
So I will say "signed: true."
So which means that my cookie-parser will ensure
that this cookie will be signed and setup.
So this is the option that I set up for the res cookie here.
So this will include
this particular name into the signed cookie with this particular value.
So that is the reason why I'm able to check that value up here.
So if this doesn't exist,
then of course I expect the user to authenticate by using the basic authentication,
and if the basic authentication is successful,
then I will set up the cookie here and set up
the cookie field in the outgoing response message here and
this will prompt the client to set up the cookie on the client side and then
all subsequent requests will include this cookie in the client request.
So that is how I am handling the fact when the cookie.user doesn't exist.
There. If it exists,
then the else part,
so that means that the signed cookie already
exists and the user property is defined on that,
then in the else,
what I will check is
if req.signedCookies.user is admin.
Then, that means that the signed cookie contains the correct information.
Then, I will say next.
So which means that you will allow the request to pass through.
Otherwise, this cookie is not valid because it doesn't contain this correct value.
So that means that this is an error.
So in this case,
we will say you're not authenticated,
and then we will simply cause the error in this point.
Now, we're not going to prompt the user for
the session because that must have been done earlier.
Now, normally, this would not happen
because if the cookie is already set on the client side,
then it must include the correct value anyway.
But for the sake of completeness,
I have also included the else error check here at this point. That's it.
With this setup, we have turned
our express application into one that handles cookies here.
Note again, let me draw your attention to what we're doing here one more time.
Here, we are checking to make sure
that user property in the signed cookies doesn't exist,
or even the signed cookie itself doesn't exist.
Then, we will expect basic authorization to be done.
If the authorization is successful,
then I am going to set up the cookie by using the res.cookie here.
Then, all subsequent requests will carry the signed cookie anyway,
and then so I'll check to see that the signed cookie is
a valid signed cookie and contains the user property which is set equal to admin.
If it does, then this is an authorized access,
so it'll allow to proceed forward.
If not, then I raise an error at this point.
Minor correction, the new versions of Node.js expect you to use this as
new Buffer.from instead of new Buffer in order to deal with some security issues.
So just correct this line to new Buffer.from. That's it.
Let's save the changes and then go and look at our application in that Postman.
If the previous server is running,
just stop it by typing Control C,
and then restart the server by saying npm start.
Of course, make sure that your MongoDB server is up and running.
Otherwise, your express server will not start correctly.
So once your express server is started,
then let's go to our Postman and try to connect to the server.
And I'll demonstrate a few aspects about how cookies are handled.
Now, going to Postman,
let me clear out all this information
from my Postman and then we'll start with the basics.
So let me try to access the localhost:3000/dishes.
Now, after I have cleared everything,
I'll send the request and save.
And so from the server side,
it says you're not authenticated.
Then, when you look at the header,
this is asking me to authenticate using the WWW-Authenticate.
So now, let me go into the authorization and then set up the basic authorization,
and then I'll set up the authorization as admin,
and then password, and then update the request so that the header
will now contain the authorization header here with the information there.
And then let me send the Git request on this part.
If I send the Git request,
then in response, you see that the Git request was successful.
Note also a few more things.
You'll see the status is 200 OK.
Note also that a cookie has been set up on our client side in within Postman here.
This cookie contains information.
We'll look at the details of the cookie in a minute.
Then, when you look at the header,
you see in the header this value here saying Set-Cookie,
and then this information that comes in here.
Now, if you look at it carefully,
you'll see something here says user equal to,
and then you see this value here, admin there.
So, you notice that something has been enclosed inside the cookie.
If you want to actually examine the cookie,
go up here in Postman and then click on these keys,
and then this will show you all the cookies that have been set up on this client side.
Then, in particular, now let me clear out all these other cookies.
I probably have used some of these for some other reason.
So let me just clean out those cookies.
Anyway, if you see them,
you can just leave them there.
Not a big problem.
Concentrate specifically on the local host here,
and then you see this cookie here.
Just click on the cookie,
and then you see the actual value inside the cookie that is stored there.
Then also the expiry date for that cookie setup here.
Now, this value will be exactly what you saw in
the set cookie that came in from the server side.
Now, this also means that in subsequent requests that go in,
so even if I clear out my authorization,
and even if I remove the authorization header,
because the cookie has been set up,
this cookie has been set up on my local host,
every subsequent request going to this this server will include this cookie.
So even though I would not have the headers set up there,
if I send the request,
you will notice that the Git request works just like before without any problem,
because of the fact that each outgoing request will automatically include
this cookie in the outgoing request from my Postman here.
This demonstrates the use of cookies in our application.
With this, we have seen how cookies can be set up and
processed in our express server using the cookie-parser,
and how we can set up signed cookies.
This is a good time for you to do a git commit with the message cookies.