Transcript
  • Web

Review of Cookies

From the class:  Session Cookies

Let's start off by reviewing what cookies are and how we can use them to maintain state. In the application function, I need to write a header. And the header is going to be a special one that tells the browser that, or any client, that it's getting a cookie. The name of the header is, set cookie. And to write headers in a Node.js, I can use the set header method of the response object.

The first parameter will be the name of the header, and then the second one will be its value. So we'll call the name of this header, set dash cookie. And the value can be whatever we want it to be. But normally you have the key of the cookie on the left hand side, so we could call that app session, for example, equals and then some value for that. We'll just say, some value. And so the thing on the left is going to be the name of the cookie, and then the thing on the right it's going to be its value.

Let's try making a request to the server now. I can use the cURL command with the I option, local host 3,000. Notice I'm logging the headers now over in the right. So you can see that we made a GET request to the root resource. And here's the headers that we sent out-- cURL actually sent these headers on our behalf by default.

And here's what we get back. We get back a 200 status code. It's OK. And here's this header that we created called, set dash cookie. And the cookie key is app underscore session. And the value is some value. Let's see what the browser does if it gets this set cookie header.

If you open up the debugger console in Chrome and click the Resources tab, look over on the left. There's a section called Cookies. And if you click on the domain, local host, you'll see all the cookies for that local domain. Our cookie, with the name app session, got created here automatically, because the browser saw that set cookie header and parsed out its name and its value.

Notice that the expires max age over here is set to session. That means that when we close this browser, the chrome software is automatically going to destroy this cookie. So it's only going to live for the time that the browser is alive.

The next thing to note is the HTTP value is blank. This means that we can access the cookie just by using JavaScript. If I open up the console in the bottom and type document dot cookie, I actually get back the value of its cookie. And I can even mutate it just using JavaScript. We can set a special flag on the cookie from the server saying that it's an HTTP only cookie, in which case we can't do this. So that's a good idea for security reasons.

The next blank spot over here says that can we transmit this cookie over a non-secure connection. So instead of using HTTPS, can we submitted over HTTP? And right now it's blank, which means that we can submit it over both protocols.

Every subsequent request that gets sent to our server from this domain is going to include this cookie. The browser's going to do that for us automatically. So it could be an image that were requesting. It could be another URL, or another path that's part of our application. But for all those HTTP requests, the browser's automatically going to send up a special header that includes this cookie. Let's do that by hand so that you can see how it works.

In the right, you can actually already see that Chrome has done this for us. Here's where Chrome made the initial request sending out these headers. And there's no cookie header in here yet Notice. It's just a bunch of headers that Chrome put in here for us automatically.

And then the next thing it does is it automatically tries to fetch this [? fiveacon ?] even though we don't have one in our application. Chrome's just doing it automatically for us. And that is another HTTP request. And what Chrome does is it adds this extra header called cookie. And its value is the cookie that we retrieved earlier.

So cookies-- this is how cookies allow us to maintain state-- is the browser will automatically send it up to the server with every feature request. We could simulate this using the cURL command as well. So if I type cURL dash I so that we can see the headers back. And then I'm going to use another option, which is capital H. That lets me pass up custom headers.

And why don't I pass up a custom cookie header? And the value will be some key equals some value. And I'll send that up to local host 30,000. OK. So what we get sent up to the servers right here, and notice the cookie header was set with some key equals some value. And we just did it by hand here.

So if we wanted to make a request to the server using just cURL, what I could do is to save away this cookie value that I get back into a file, or you can imagine some other store. I could just save it in memory. And then what I could do is on every subsequent request, pass it up as this value to the cookie header. And that would allow us to maintain state with the server.

It's also possible to send more than one cookie in a request. And I've made the windows sit on top of each other so that this is easier to see. This time I'll make a request, and I'll use the header option again providing a cookie. And I'll have my first cookie equals some value. Maybe I'll just call it V1. And now to pass another cookie, I can use the semicolon and the space. So this will be the second cookie equals V2, or whatever we want to be.

Now, the cookie that gets passed up to the server, which is represented here, has two cookies. And they're delimited by the semicolon and a space.