WEBVTT 00:02.110 --> 00:07.440 So this time around, we want to get started on this sort of thing right now, I'm logged in and I'm 00:07.480 --> 00:10.450 on the virtual terminal page, just click on it and here I am. 00:10.900 --> 00:19.720 And if I copy that URL and a log out and then paste that, you are all back into the location bar of 00:19.720 --> 00:24.800 my browser, I have no problem seeing that page and we don't want that to be possible. 00:24.820 --> 00:27.860 This should be a page that only authenticated users can see. 00:28.590 --> 00:30.820 Now, there's a couple of ways of doing this. 00:30.830 --> 00:36.730 And if we were to do everything completely divorced from the front end, in other words, all of our 00:36.730 --> 00:39.610 authentication is handled by our API server. 00:40.390 --> 00:41.200 We can do that. 00:41.410 --> 00:46.300 But it's kind of awkward and it's kind of awkward because in effect, I have a couple of options. 00:47.140 --> 00:53.950 One is to make the rules that appear in my menu items, say the one for virtual terminal, make those 00:53.950 --> 01:00.610 not standard eight aircrafts, but instead make them call some JavaScript function, which first goes 01:00.610 --> 01:03.070 and verifies against the back that you're authenticated. 01:03.280 --> 01:06.610 And if it is, then it redirects you to a particular page. 01:07.060 --> 01:09.250 And that's one option. 01:09.250 --> 01:11.320 But it gets really awkward really fast. 01:11.470 --> 01:17.200 The other one, of course, is to actually allow authentication to the back end like we have right now, 01:17.200 --> 01:23.440 but also when we authenticate to also authenticate through the front end and store some special variable, 01:23.800 --> 01:27.250 which we can check on every request to see if the users authenticate it or not. 01:27.910 --> 01:34.960 Now, if this was a single page application, something built in react to review, this wouldn't be 01:34.960 --> 01:40.150 an issue because a single page application is, as its name implies, one page. 01:40.360 --> 01:44.250 And we could do all of our authentication through the back end without any difficulty whatsoever. 01:44.650 --> 01:45.910 But this is not so. 01:46.030 --> 01:50.200 We'll do both ways and we'll start with authentication through the backend. 01:50.260 --> 01:57.850 So let me go back to my ID and let's go to base layout Dudko HTML and we'll put it in. 01:57.850 --> 02:03.610 Here is a function that's available on every page, just like the function log out and I call this function 02:05.560 --> 02:08.740 check off and it takes no parameters. 02:09.490 --> 02:15.880 And what this is going to do is to check to see if the user authenticated by doing a fetch request to 02:15.880 --> 02:16.690 the back end server. 02:16.960 --> 02:22.660 OK, so we'll just check to see if local storage, if that has the item. 02:22.670 --> 02:26.590 So we'll get the item, get item token if it's equal. 02:26.590 --> 02:27.130 Exactly. 02:27.130 --> 02:32.110 To know if it doesn't exist, then we're going to do something else. 02:32.800 --> 02:33.740 We'll do something else. 02:34.360 --> 02:38.470 So what we'll do if they're not logged in, let's say we call this function to check authentication, 02:38.920 --> 02:41.310 we'll just take them to the login page if they're not logged in. 02:41.320 --> 02:51.290 So location F is equal to the home or to the login page and will return. 02:51.430 --> 02:52.350 We don't want to go any further. 02:53.860 --> 03:00.670 So if that's not the case, then we want to actually get the token from storage. 03:00.700 --> 03:08.130 So we'll say let token equal local storage, get a token. 03:11.020 --> 03:17.500 Then we'll create a headers variable const my headers and we're going to use this for fetch is equal 03:17.500 --> 03:19.390 to a new headers. 03:22.170 --> 03:30.660 And we'll spend a few things to it, so will my headers append what we're going to append first is the 03:30.660 --> 03:40.290 content type content dash type and we'll make it application duration, JSON, and then I'll duplicate 03:40.290 --> 03:43.220 this and I'm going to spend another header. 03:43.230 --> 03:44.970 And this one is authorization. 03:44.970 --> 03:48.720 And it's critical that you spell this right authorization. 03:48.960 --> 03:50.120 And I'll show you why in a bit. 03:51.270 --> 03:59.580 And this is going to be equal to a very specific syntax, the word barer with a capital B, then a space. 04:00.180 --> 04:05.610 And then I'm going to add to that the contents of my token that I pulled from local storage. 04:06.420 --> 04:09.080 And it has to be barer space and then the token. 04:09.900 --> 04:10.730 So we've got our headers. 04:11.190 --> 04:13.440 Now let's create a request options variable. 04:13.440 --> 04:15.150 So const request options. 04:15.160 --> 04:19.680 And again, I'm going to use this with my statement. 04:21.150 --> 04:23.910 That's a JavaScript object and it just has a method. 04:24.370 --> 04:26.070 We're going to make this a post request. 04:26.070 --> 04:27.360 We'll post at the back end. 04:27.960 --> 04:33.240 And it's headers are equal to my headers, the variable we just created, which includes the content 04:33.240 --> 04:36.720 type and our authorization header with our barer token. 04:37.020 --> 04:41.730 OK, now we'll call a non-existent URL on the back end. 04:41.730 --> 04:47.040 So we'll call FEG and we're going to use our API URL. 04:47.040 --> 04:54.720 So API in curly brackets, double curly brackets like that, then slash API and we'll just call is authenticated, 04:54.750 --> 04:58.830 which doesn't exist, but we'll create in a minute is authenticated. 05:01.510 --> 05:08.920 And we'll pass at our request options, then we'll have our first then statement that takes the response 05:11.500 --> 05:21.010 in terms of administration response to Jason and give yourself some room on our final. 05:21.010 --> 05:28.810 Then Claw's will be a function that takes data which is now in the form of Jason, and we'll do something 05:28.810 --> 05:29.050 with it. 05:30.700 --> 05:32.920 And what we're going to do is very simple right now. 05:32.920 --> 05:39.790 We'll just say if the response that we get back has an error that is exactly equal to true, then we'll 05:39.790 --> 05:47.470 just say console dialog not logged in just so we can see what's going on. 05:50.300 --> 05:50.990 Otherwise, 05:54.110 --> 05:54.680 ELT's. 05:57.140 --> 06:04.030 We will, not surprisingly, say console dialogue logged in, OK? 06:05.180 --> 06:14.690 And semicolon there so this world doesn't exist, so let's go over to our roots Dash API ago and you 06:14.690 --> 06:18.740 remember here, I said we're going to have an authorization header and it's critical that you spelled 06:18.740 --> 06:19.460 that correctly. 06:19.850 --> 06:25.730 But if you look at rootstock roots dash API, don't go here in allowed headers. 06:25.730 --> 06:27.180 We have authorization. 06:27.230 --> 06:28.910 That's one of the headers we're accepting. 06:28.910 --> 06:31.520 And this is the these are the only headers we're accepting. 06:31.530 --> 06:36.890 OK, so that needs to be set to the correct spelling in your JavaScript. 06:37.430 --> 06:40.940 Now you might think why aren't you turning allow credentials to true here? 06:41.210 --> 06:43.850 Because that's not the kind of credentials we're using. 06:43.880 --> 06:51.410 That would be standard HTTP credentials or a client site SSL certificate with a specific format or signature, 06:51.410 --> 06:52.010 that sort of thing. 06:52.040 --> 06:52.520 So we can leave. 06:52.520 --> 06:53.240 That's a default. 06:53.390 --> 06:58.850 But what we do need to do is to come down here and create a new route Muxtape Post. 06:59.330 --> 07:07.010 And if you recall, I said it's API slash, API is authenticated and we'll make that point to a handler 07:07.010 --> 07:10.880 that doesn't exist yet, which I'll call check authentication. 07:13.590 --> 07:20.370 OK, now that doesn't exist, so let's go back over to our handlers for our API, stroll to the very 07:20.370 --> 07:24.840 bottom and create that handler and we'll make it really simple for right now. 07:24.840 --> 07:30.900 So frunk with the receiver of pointer to application and it's got to be called check authentication 07:31.500 --> 07:34.170 and it takes the response rate or in the request 07:37.650 --> 07:38.730 pointed to a request. 07:40.860 --> 07:44.810 And all I'm going to do right now is send back an invalid credentials response. 07:44.810 --> 07:47.520 So I'll call apter invalid credentials. 07:47.520 --> 07:49.390 And all that requires is a response rate. 07:49.600 --> 07:51.240 OK, so that's now set up. 07:52.350 --> 07:58.830 So we have this function back in basic HTML checkoffs, which we'll call this, and it should always 07:58.830 --> 08:00.140 give us not logged in. 08:00.150 --> 08:02.200 We should get an invalid credentials response. 08:02.220 --> 08:09.580 OK, so now let's open our virtual terminal page, which is called Terminal Dot Page HTML and scroll 08:09.580 --> 08:13.590 to the very bottom and just call that script and we'll call it. 08:14.130 --> 08:16.860 It's called check off like that. 08:17.820 --> 08:20.730 So if we did everything right, I should be able to stop my application. 08:21.120 --> 08:21.510 Stop. 08:23.280 --> 08:24.000 They start. 08:29.850 --> 08:37.680 And go back to my Web browser and open the JavaScript console and clear it and go to the home page. 08:38.650 --> 08:39.400 OK, that's fine. 08:40.050 --> 08:43.020 Now let's go to slash virtual terminal. 08:47.040 --> 08:48.330 So take us to the login page. 08:48.390 --> 08:54.830 That's exactly what it should have done because I don't have a token in my local storage. 08:54.870 --> 09:02.130 So this time let's log in and let's put in valid credentials in at example, dot com and password. 09:04.640 --> 09:09.770 So we're logged in now, we'll go to the virtual terminal page and this time watch the JavaScript console 09:09.770 --> 09:10.590 very closely. 09:12.830 --> 09:17.240 It gave us a not logged in message and we didn't do anything with that message. 09:17.570 --> 09:25.160 But of course, this is the sort of situation where we can and will if a user tries to go to a page 09:25.160 --> 09:29.810 that is a protected route, we can verify whether or not they're logged in by calling that check off 09:29.810 --> 09:30.570 and then do something. 09:30.590 --> 09:31.650 So let's go back here. 09:31.700 --> 09:32.870 Let's go back to the home page. 09:34.070 --> 09:35.390 So be refreshing this in a bit. 09:35.650 --> 09:43.250 Go back to our JavaScript or our ID and find that checkoff function, which is in base layout. 09:44.180 --> 09:48.290 And instead of just saying not logged in, let's say location 09:50.630 --> 09:52.200 equals slash log in. 09:53.160 --> 09:59.780 OK, so we start my application, make stuff like start. 10:05.180 --> 10:11.210 OK, I should still be logged in, so if I go to the products page and look at my one widget, she still 10:11.210 --> 10:11.800 says log. 10:11.840 --> 10:17.720 But now when I go to the virtual terminal, because my back end is sending back those invalid credentials 10:17.720 --> 10:20.090 response, it should take me to the login page. 10:22.400 --> 10:23.060 And it did. 10:23.360 --> 10:26.000 Now you can see the drawback very briefly. 10:26.210 --> 10:32.780 I saw the virtual terminal page and that's why this kind of authentication check using only the back 10:32.780 --> 10:34.730 end as we are right now. 10:35.000 --> 10:38.720 It's not ideal for applications that are not single page applications. 10:38.750 --> 10:40.190 Now, there are ways around this. 10:40.460 --> 10:45.920 You can, of course, hide the content until you do your verification and then only display the content 10:45.920 --> 10:51.140 after you get the appropriate response from the back end saying you're validated, but it gets awkward 10:51.140 --> 10:52.560 and it gets awkward in a hurry. 10:52.910 --> 10:56.080 So this is one way of protecting a page and obviously we're not done yet. 10:56.090 --> 11:02.570 We need to actually do the logic in that check authentication method over the API handlers to actually 11:02.570 --> 11:04.310 validate that token. 11:04.580 --> 11:05.680 And we'll do that shortly. 11:06.560 --> 11:11.870 But obviously, for an application like this, like the one we're building in this course, having another 11:11.870 --> 11:16.790 kind of authentication, front end authentication is actually pretty useful and we'll take care of that 11:16.790 --> 11:17.300 as well. 11:17.300 --> 11:19.910 So you'll know how to approach it from both perspectives.