00:00 We're going to manage this cookie in a util. So let's come to our utils. We're going to make a new one called toast.server.ts. And in here, we're going to be using a create cookie session storage from RemixRunNode.

00:15 And this is going to get us our toast session storage. We're going to export that. And here, we're going to configure our cookie with a couple of options. So we want the name to be en underscore toast. So that's en short for Epic Notes.

00:35 And then we have same site. We're going to configure that to lax. That means that if a user is coming over to our site from somebody else's site, this cookie will be available. And for a toast message, that could be pretty useful if we link to the user in an email.

00:53 We send them an email with a link. And that's going to come over, and maybe they have a toast message in their cookie or something like that. Same site lax is what we do most of the time with our cookies. And so it's a pretty safe default. And in fact, I think it is the default anyway. OK, so we also want it to be path slash.

01:11 So you can actually configure this to be only this route. And that will apply to only that route and subroutes. But we want this applied to the whole site. So we'll say path is slash. Also, HTTP only, we want that to be true. We don't want extensions or whatever to set this cookie or have access to this.

01:30 This is only for our server side that's going to be able to change this cookie. And then we're going to have secure. That's going to be based on whether we're running in production. By default, Chromium-based browsers and Firefox will actually work just fine by saying secure true, as far as localhost is concerned.

01:49 So you can still do HTTP on localhost, and secure will still work. But Safari will not. So you would have to run an HTTPS server locally for secure to work. So that's a bit of work, and it's not really all that necessary to have it be secure during local.

02:08 So we're going to set secure to true in production only. And then we're going to say secrets. Now, secrets allows us to encode or to sign our cookies so that we know whether our cookies were tampered with. So the value of the cookie itself

02:26 can be decoded on the client, except for the fact that we have HTTP only. But it could be decoded if a user looked in there at DevTools or whatever. You don't put anything secret inside of a cookie. But by supplying the secrets, it will mean that the cookie will be signed.

02:46 And so what that means is when we're reading the cookie back on the server, we're going to check to make sure that it was signed properly with our secret. And if it was, then we can trust it. If it wasn't, then we don't trust it. So secrets is actually an array of different secret options.

03:02 Because if you think about it for a second, like let's say that you have a secret, and you've been signing a bunch of cookies with that secret. And then that secret gets out somehow. And so now people can make their own cookies. You don't want them to be able to do that, right? That would not be good.

03:21 And so you're going to switch to a different secret, right? But now all of the cookies that you've made for all time are now invalid. That's not good. And so what we do is actually we have an array of secrets. And the first one is the one that's going to be used to sign stuff. But the rest of them will be available in the event

03:40 that the first one doesn't check properly. So like when the cookie comes in, we're going to check that it was signed properly with the first secret. And if that one doesn't work, then we'll check the next secret. So that way you can still verify old ones, but new ones can't be created with the new one.

04:00 And so you can have rolling secrets this way. OK, so with that, we're going to say process env.sessionSecret.split, and comma. So we actually already have a session secret that we set from our previous workshop. So we're just going to take the comma-separated session secrets.

04:20 That's all configured in our .env right here. Of course, that's not the actual value. And then our env server will verify that that thing is set properly as well. So with that, we are all set to start making some session storage values for our toast messages.

04:39 We unfortunately can't really test this with anything yet. That'll be for a future step. But hopefully that gives you an idea of creating a cookie session storage and configuring the cookie for it. And yeah, that's a good time.