In the last video he came to the realization that we should probably be making use of Jason Webb tokens.
But now we need to decide how we are going to communicate that Jason Webb token over to our back end
services.
So in this video I want to lay out a couple of further requirements of our application.
All right.
So first a quick diagram here just to give you a quick reminder on what goes on during the loading process
of an application into the browser when we are writing a normal react application.
This might not seem relevant to this Jason Webb token question at all but trust me it is extremely extremely
relevant.
So first just a quick reminder of how a normal react application works.
OK I'm going to zoom in here.
I start off at the very top so you're going to imagine that a user types out ticketing dot Dev into
their address bar and hits enter as soon as that is done your browser is going to make a get request
to ticketing dot Dev then with a typical react application we are going to then immediately send back
in each demo file that is pretty much bare bones there's not really gonna be anything inside there except
for a little bit of HD e-mail some script tags some C Ss tags maybe some other stuff but for the most
part there's not going be a lot of markup inside that file that file is then going to be loaded up by
the browser the browser is going to see all those script tags and it's going to decide oh I need to
make a followup request to the back end client and get all the associated JavaScript files to actually
boot up and execute this react application.
So we're gonna make a follow up request for some JavaScript files.
These are technically all separate requests but whatever if there are multiple files we're going to
send back all these different JavaScript files and the browser is going to execute the code inside them.
That is when our ReACT application is going to actually boot up inside the browser.
And at that point in time we might need to make some requests to get some data.
The react app at that point might make a request over to the order service asking for some data and
the order service will respond with that orders data react application will then take that info build
some H T mail and display on the screen to show to the users.
So again that is the normal flow of a typical react application.
Now quick question for you we are taking a look at more or less three requests here.
The initial request a follow up request to get some javascript files or SS files or whatever else and
then a third request right here to get some actual data that the application needs.
So considering these three requests at what point in time do we need to somehow communicate authentication
information from the browser over to the back end.
Well we probably don't really need to do it.
We don't really need to know if this user is logged in during the initial request.
There might be some scenarios where we do not even want to send a user a react application if they are
not logged in.
But for the most part we usually say that we don't really care about sending out the source code for
a react app.
You might think to yourself Well Steven do we want to secure the source code.
To be honest no that's not something it's very commonly done in the production world.
So during that initial request with a normal react up we really don't care about authentication.
Do we need to know about authentication with JavaScript files.
Well no for the same reasons we don't really care if users logged in.
Sure they could have some javascript code go for it.
Take it.
I don't care.
The only time that we really care about whether or not a user is logged in is when they start asking
for data so we would really say that for a normal react application right here is really the soonest
point in time we ever need to start to worry about sending authentication data over to the server.
We need to include authentication data.
So specifically the states on a Web token inside of this request right here to our back end order service
because the order service probably needs to know about whether or not this user user is logged in and
whether they have permission to view this data or whatever else OK.
So again that request right there would probably be the soonest that we would want to think about including
that Jason web token and we would probably include that in the headers or some authorization header
of the request in the body of the request or alternatively maybe by using that cookie mechanism as well.
All three these would work with a normal react application.
You'll notice that I'm stressing the term normal here.
So as a reminder we are not really building a very normal react application.
Instead we are building a server side rendered react application.
The idea behind a server side rendered react up is that we are going to make some initial request to
some back end server.
This back in server is then going to render out or build the h t mail for our entire app and then send
that A.T.M. file with all the content inside of it all the relevant orders or tickets or whatever else
already rendered.
As each team.
We're going to send that response backwards the browser the browser is going to get that e-mail file
and instantly have some content to show to the user on the screen without having to make all those follow
up requests to get some javascript files.
And another request to get some data the whole reason we are using the server side rendering approach
is for SEO purposes.
Search engine optimization and also page load speed.
If our user has the older device or a mobile device for that matter let's think about what this really
means to be able to send back an HMO file with all the relevant content inside of it.
From the very first request that means that our client whatever we built here this next JSA application.
That's how we're going to do this server side rendering stuff.
We're going to use a framework called Next J.S..
That means that this next J.S. process right here is going to have to fetch some data.
So that means that that thing is going to have to reach out directly in one way or another to our order
service or the ticketing service or whatever else it needs to get that information.
So an immediate response with some relevant content so with our approach you're using the server side
rendering without a doubt.
We need to know authentication information with the very first request.
This very first request right here we need to communicate that JS on web token.
So that very first request needs to have that authorization header or a token in the body or the token
inside of some cookie or something like that.
Now this really presents a big issue.
Let me tell you why when you type in say Google dot com into your address bar and hit Enter Google has
no ability to run any javascript code on your computer before sending you an HMO file when you hit enter.
The first thing is going to happen you are going to get back an e-mail file and inside that HMO file
we can have some javascript code or a reference to a script tag to load up some code and then at that
point in time Google can start to reach around and try to find a token stored on your device or something
like that.
But the point is that during that initial page load request when we press enter into our address bar
to go to some domain we can not customize that initial request in any way.
We can not somehow execute some javascript code ahead of time or anything like that so that has a really
big impact.
That means that we cannot run some custom code to intercept that initial page load and try to append
an authorization header in that request.
We cannot tried to add in a token to the body of the request so that means that both of these methods
of sharing the Jason web token with our back and server go out the window when we are doing server side
rendering if we want to tell that server who we are or communicate any information during that initial
page load request that information absolutely positively has to be stored inside of a cookie.
Because only this cookie is Cookie right here that is the only way for us to somehow communicate information
from our browser to that back end.
During the initial page load.
Now having said that there is technically a very small corner case we can get around this by using service
workers but that's really way outside the scope of what we're doing here with our ReACT application
and a general service workers.
It is a pretty big architectural change to our ReACT application and it would require a lot more integration
with next gen us.
So that's really something we're not really going to consider here even though I just want it out there
technically as a workaround for this.
So long story short because we are doing server side rendering and because this first request needs
to have authentication information and because we cannot customize that request in any way to try to
attach on an additional header or some information side the body we have to communicate our Jason web
token inside of a cookie.
It's a hard requirement.
So at this point we've essentially established that we're going to use a Jason web token and it's gonna
be stored inside of a cookie and that's why a little bit ago I made kind of a big deal about reviewing
the differences differences between cookies and Jason web tokens because again a lot of time when we
hear about Cookie based authentication we just think oh this is something totally different than Jason
a token.
No it's not.
Cookies are a transport mechanism there's something we use to move information around.
We can store a Jason web token or move a Jason web token around inside of a cookie but whenever you
hear about cookie based authentication the assumption a lot of engineers make is that we are somehow
creating a customized token or something like that and storing inside of a cookie.
Yeah that's totally valid.
We could totally do that but it's not mutually exclusive with using Jason web tokens we can use.
Cookies and Jason web tokens together.
And that's exactly what we were going to do to solve this server side rendering issue.
All right.
We've gone through a couple of very lucky videos now.
I apologize for the duration but we are essentially all done with the background on this authentication
stuff.
Going to take a pause right here and start to build out our authentication system for real in the next
video.