Okay.
And the next feature I want to add to our app is the HTTP only cookie.
You see at the moment we send back JWT with our JSON response and on the front end we store it in the
state and the local storage.
And while overall it's a valid authentication approach, since local storage can be accessed with the
JavaScript, there are some security concerns.
What's the solution?
Well, instead of JSON response, we will send our token with HTTP only cookie, which can be accessed
only by the browser and not the JavaScript.
Additionally, we won't need to worry about storing the token in the state or local storage since the
browser will automatically send it back.
Essentially, cookies also simplify the front end setup.
And if this sounds somewhat confusing, don't worry.
You'll see once we start working on the feature.
Before I show you the end result, let me mention a few important things.
First, since we're adding this feature later, please be prepared to refactor your code.
I know some people don't like refactoring.
I hear you.
But unfortunately, there's nothing I can do about it.
In my opinion, it's important that you are aware of both approaches, local storage and the cooking.
And therefore first we worked on the local storage option and now we refactor it to cookies.
Please don't rush through the videos.
There are quite a few small changes we need to make and it's easy to make a typo and as a result you'll
get a hard to find bug, especially again if you're rushing through the content.
So my suggestion is to check a few times before adding the code and especially especially before removing
the code.
Lastly, cookies are sent back only to the same domain by default.
So remember.
When we set up the proxy in the client.
This sucker over here.
Essentially, we just made sure that both of our applications, the front end one and the server are
on the same domain.
And therefore, remember, we could just use the forward slash in the front end and also on the server.
We didn't have to use the course library.
So the same works with cookies.
By default, they are sent back only to the same domain.
What that means in our setup, they will work right out of the gate.
In the dev setup now in production.
The reason why they are going to work is because we have expressed static.
We grab the client production or the application and we set it up as our static assets.
Again, they will work.
In production.
And if you're wondering, okay, but when is this setup not going to work?
Well, it's not going to work if the client is deployed on a separate server.
So if the client is on one server and then the server server, meaning our server over here is on the
different server, then by default they're not going to work.
You'll have to do some acrobatics and just to showcase that.
I'm going to show you the code that I use for Phi.
Please keep in mind, if you're using different service, most likely your code is going to be a little
bit different.
So if you navigate to the source and I mean, of course, that is in the complete application.
So if you navigate here to the redirect, which you'll notice is the forward slash API four slash star.
Remember how all our URLs start with API version one, blah blah blah, blah blah.
Correct.
So here's what I'm doing on Amplify and basically say.
All the requests that are going to go to four slash API four slash star.
So anything after that are actually going to go to my render server.
And as a result, I'm actually able to get those cookies from the.
Application that's on the lender.
Again, it's not going to happen by default.
And the reason why I'm spending so much time on this is because.
I get a lot of questions on this in my courses.
People are like, Hey, you showed us the cookies, but why they don't work?
They will only work if both of them are on the same server.
And effectively, you can think of this as a hack.
I mean, it's not really a hack.
It's a redirect that you can set up with in this case nullify.
But in general, this is what you'll have to do.
Be prepared to do some acrobatics.
If the applications are on a separate servers by default, they will work only if they're on the same
server.
Hopefully that is clear.
And so now let me show you the end result.
So at the moment I'm sitting in my production application.
Notice I'm on the landing page and everything is great.
And if I take a look at the.
Application time.
I can clearly see that I have nothing in the local storage, nothing.
Zero.
And also I open up the cookies because this is where we will see the interesting info.
And if I'm going to go to login and I'm going to.
Provide my credentials.
You'll say something really cool where, yes, the logging was successful, but again, we're not storing
anything in a local storage, so local storage is clean.
There's nothing there.
And also, if you take a look at the components and the state, you'll notice that I'm not storing a
token over there and everything works.
So even if I refresh, I still get the data about the user.
And again, nothing is stored in the local storage.
So how everything works?
Well, if we take a look at the cookies.
Notice this is where we have the token and this is HTTP only cookie, which means, again, it can be
only accessed by the browser.
And we also have the secure flag, which means that it's only going to work with a ship.
Yes.
And some exploration and all that cool stuff.
And you can try any of these routes and you'll see that everything still works without storing anything
in the local storage.
So now that we are aware of what we are trying to build, let's proceed.