So this time around, we want to get started on this sort of thing right now, I'm logged in and I'm
on the virtual terminal page, just click on it and here I am.
And if I copy that URL and a log out and then paste that, you are all back into the location bar of
my browser, I have no problem seeing that page and we don't want that to be possible.
This should be a page that only authenticated users can see.
Now, there's a couple of ways of doing this.
And if we were to do everything completely divorced from the front end, in other words, all of our
authentication is handled by our API server.
We can do that.
But it's kind of awkward and it's kind of awkward because in effect, I have a couple of options.
One is to make the rules that appear in my menu items, say the one for virtual terminal, make those
not standard eight aircrafts, but instead make them call some JavaScript function, which first goes
and verifies against the back that you're authenticated.
And if it is, then it redirects you to a particular page.
And that's one option.
But it gets really awkward really fast.
The other one, of course, is to actually allow authentication to the back end like we have right now,
but also when we authenticate to also authenticate through the front end and store some special variable,
which we can check on every request to see if the users authenticate it or not.
Now, if this was a single page application, something built in react to review, this wouldn't be
an issue because a single page application is, as its name implies, one page.
And we could do all of our authentication through the back end without any difficulty whatsoever.
But this is not so.
We'll do both ways and we'll start with authentication through the backend.
So let me go back to my ID and let's go to base layout Dudko HTML and we'll put it in.
Here is a function that's available on every page, just like the function log out and I call this function
check off and it takes no parameters.
And what this is going to do is to check to see if the user authenticated by doing a fetch request to
the back end server.
OK, so we'll just check to see if local storage, if that has the item.
So we'll get the item, get item token if it's equal.
Exactly.
To know if it doesn't exist, then we're going to do something else.
We'll do something else.
So what we'll do if they're not logged in, let's say we call this function to check authentication,
we'll just take them to the login page if they're not logged in.
So location F is equal to the home or to the login page and will return.
We don't want to go any further.
So if that's not the case, then we want to actually get the token from storage.
So we'll say let token equal local storage, get a token.
Then we'll create a headers variable const my headers and we're going to use this for fetch is equal
to a new headers.
And we'll spend a few things to it, so will my headers append what we're going to append first is the
content type content dash type and we'll make it application duration, JSON, and then I'll duplicate
this and I'm going to spend another header.
And this one is authorization.
And it's critical that you spell this right authorization.
And I'll show you why in a bit.
And this is going to be equal to a very specific syntax, the word barer with a capital B, then a space.
And then I'm going to add to that the contents of my token that I pulled from local storage.
And it has to be barer space and then the token.
So we've got our headers.
Now let's create a request options variable.
So const request options.
And again, I'm going to use this with my statement.
That's a JavaScript object and it just has a method.
We're going to make this a post request.
We'll post at the back end.
And it's headers are equal to my headers, the variable we just created, which includes the content
type and our authorization header with our barer token.
OK, now we'll call a non-existent URL on the back end.
So we'll call FEG and we're going to use our API URL.
So API in curly brackets, double curly brackets like that, then slash API and we'll just call is authenticated,
which doesn't exist, but we'll create in a minute is authenticated.
And we'll pass at our request options, then we'll have our first then statement that takes the response
in terms of administration response to Jason and give yourself some room on our final.
Then Claw's will be a function that takes data which is now in the form of Jason, and we'll do something
with it.
And what we're going to do is very simple right now.
We'll just say if the response that we get back has an error that is exactly equal to true, then we'll
just say console dialog not logged in just so we can see what's going on.
Otherwise,
ELT's.
We will, not surprisingly, say console dialogue logged in, OK?
And semicolon there so this world doesn't exist, so let's go over to our roots Dash API ago and you
remember here, I said we're going to have an authorization header and it's critical that you spelled
that correctly.
But if you look at rootstock roots dash API, don't go here in allowed headers.
We have authorization.
That's one of the headers we're accepting.
And this is the these are the only headers we're accepting.
OK, so that needs to be set to the correct spelling in your JavaScript.
Now you might think why aren't you turning allow credentials to true here?
Because that's not the kind of credentials we're using.
That would be standard HTTP credentials or a client site SSL certificate with a specific format or signature,
that sort of thing.
So we can leave.
That's a default.
But what we do need to do is to come down here and create a new route Muxtape Post.
And if you recall, I said it's API slash, API is authenticated and we'll make that point to a handler
that doesn't exist yet, which I'll call check authentication.
OK, now that doesn't exist, so let's go back over to our handlers for our API, stroll to the very
bottom and create that handler and we'll make it really simple for right now.
So frunk with the receiver of pointer to application and it's got to be called check authentication
and it takes the response rate or in the request
pointed to a request.
And all I'm going to do right now is send back an invalid credentials response.
So I'll call apter invalid credentials.
And all that requires is a response rate.
OK, so that's now set up.
So we have this function back in basic HTML checkoffs, which we'll call this, and it should always
give us not logged in.
We should get an invalid credentials response.
OK, so now let's open our virtual terminal page, which is called Terminal Dot Page HTML and scroll
to the very bottom and just call that script and we'll call it.
It's called check off like that.
So if we did everything right, I should be able to stop my application.
Stop.
They start.
And go back to my Web browser and open the JavaScript console and clear it and go to the home page.
OK, that's fine.
Now let's go to slash virtual terminal.
So take us to the login page.
That's exactly what it should have done because I don't have a token in my local storage.
So this time let's log in and let's put in valid credentials in at example, dot com and password.
So we're logged in now, we'll go to the virtual terminal page and this time watch the JavaScript console
very closely.
It gave us a not logged in message and we didn't do anything with that message.
But of course, this is the sort of situation where we can and will if a user tries to go to a page
that is a protected route, we can verify whether or not they're logged in by calling that check off
and then do something.
So let's go back here.
Let's go back to the home page.
So be refreshing this in a bit.
Go back to our JavaScript or our ID and find that checkoff function, which is in base layout.
And instead of just saying not logged in, let's say location
equals slash log in.
OK, so we start my application, make stuff like start.
OK, I should still be logged in, so if I go to the products page and look at my one widget, she still
says log.
But now when I go to the virtual terminal, because my back end is sending back those invalid credentials
response, it should take me to the login page.
And it did.
Now you can see the drawback very briefly.
I saw the virtual terminal page and that's why this kind of authentication check using only the back
end as we are right now.
It's not ideal for applications that are not single page applications.
Now, there are ways around this.
You can, of course, hide the content until you do your verification and then only display the content
after you get the appropriate response from the back end saying you're validated, but it gets awkward
and it gets awkward in a hurry.
So this is one way of protecting a page and obviously we're not done yet.
We need to actually do the logic in that check authentication method over the API handlers to actually
validate that token.
And we'll do that shortly.
But obviously, for an application like this, like the one we're building in this course, having another
kind of authentication, front end authentication is actually pretty useful and we'll take care of that
as well.
So you'll know how to approach it from both perspectives.