WEBVTT 00:03.730 --> 00:04.600 Hey, did everyone. 00:04.690 --> 00:05.140 They sure. 00:05.140 --> 00:06.640 And welcome to another video. 00:06.670 --> 00:08.140 In this video, we're going to see that. 00:08.140 --> 00:11.710 What are the issues that didn't come up when we are trying to protect it out? 00:11.710 --> 00:13.500 And what do I mean by protecting it out? 00:13.510 --> 00:17.170 Let's go ahead and work on with that and explain you a little bit more onto that. 00:17.410 --> 00:23.050 So so far we have understood quite in detail about the login and the register, but the point is what 00:23.050 --> 00:28.240 is the use of this login register of course to protect some of the information so that only logged in 00:28.240 --> 00:30.010 user can access that information. 00:30.010 --> 00:30.910 Pretty obvious. 00:30.910 --> 00:34.000 But how we can actually protect that, that is the big question. 00:34.000 --> 00:36.340 So let's just say we have designed this route. 00:36.340 --> 00:41.200 We're going to simply create a get route and it can be for getting the product information, maybe some 00:41.200 --> 00:44.470 sensitive information like who has placed the order on your website or not. 00:44.470 --> 00:46.270 That should be really personal to you. 00:46.270 --> 00:49.150 And that all information may be is that dashboard. 00:49.150 --> 00:52.960 So all of that and we really don't care right now how that information goes there. 00:52.960 --> 00:54.340 But let's just say it is there. 00:54.610 --> 01:00.340 As of now, we're going to go ahead and simply say that this is my request, this is my response, and 01:00.340 --> 01:01.120 there we go. 01:01.300 --> 01:04.630 So let's just go ahead and send this one here. 01:05.320 --> 01:06.550 So red dots send. 01:06.580 --> 01:10.660 Yes, I know we should be sending the resident status and everything, but now you are aware of that. 01:10.660 --> 01:12.100 So I will not do that again. 01:12.100 --> 01:20.140 So let's don't send and we're going to simply say welcome, welcome to secret information. 01:20.290 --> 01:21.580 So that sounds great. 01:21.760 --> 01:24.790 Okay, now let's go ahead and try to hit this dashboard route. 01:24.790 --> 01:30.610 So let's go up here in the postman and we're going to go ahead and remove all of this and we're going 01:30.610 --> 01:34.480 to say dash dashboard. 01:34.780 --> 01:35.530 There we go. 01:35.770 --> 01:41.350 And if I try to go ahead and hit the get root on this one and send this one, we get this information. 01:41.350 --> 01:43.060 Welcome to the secret information. 01:43.060 --> 01:46.570 So what is stopping me to actually go ahead and get this route? 01:46.660 --> 01:47.530 Nothing. 01:47.530 --> 01:49.570 Honestly, nothing is stopping me right now. 01:49.570 --> 01:54.130 And that's where this login and register actually comes in, because if the user is already there, 01:54.130 --> 01:59.020 I can actually log him in and once I log in him, that's where the our token actually comes into the 01:59.020 --> 01:59.650 picture. 01:59.650 --> 02:01.840 So let's go ahead and talk about this token. 02:01.840 --> 02:06.310 And also I would like to talk about a little bit of the strategies that can come in, because when you 02:06.310 --> 02:11.680 go ahead and try to use this token, there can be a lot of places where you can place the token as frontend 02:11.680 --> 02:13.990 engineer and you can expect that into the back end. 02:13.990 --> 02:15.610 So let's go ahead and work on with that. 02:15.670 --> 02:17.890 So first, how you're going to protect that out. 02:17.890 --> 02:22.000 Remember we talked about the middleware that something happens and after that something happens. 02:22.000 --> 02:25.720 Yes, that's exactly is going to help us to protect the route. 02:25.720 --> 02:27.970 So this is the strategy that we are going to follow. 02:27.970 --> 02:32.080 First, to use the middleware, of course, we don't know right now how to use that, but yes, we can 02:32.080 --> 02:32.950 use the middleware. 02:33.160 --> 02:37.630 So how we're going to do that is we are going to learn how to write the middleware, super easy to do 02:37.630 --> 02:39.310 nothing more than just a function. 02:39.400 --> 02:43.900 Then in that middleware, the functionality that we are going to build in is first check for the token 02:43.900 --> 02:44.320 presence. 02:44.320 --> 02:48.730 Now this in itself is a really complex thing that you have to figure out that whether you are going 02:48.730 --> 02:53.830 to support the mobile app or just the web app and maybe in the mobile app, 40 are supporting Android, 02:53.830 --> 02:57.010 iOS, Flutter, React Native or maybe something else. 02:57.010 --> 03:01.870 Because based on what the framework is, you have to see that where that token can goes on. 03:01.870 --> 03:06.040 I will come back onto this point just in a minute, but first, let's go ahead and work with that. 03:06.040 --> 03:10.420 Suppose somehow you have grabbed this token, now it's time to verify that token. 03:10.420 --> 03:16.420 So JWT allows you to verify that token that whether this token has expired or it is is still authenticated 03:16.420 --> 03:21.040 or is it generated using your secret only since you only know the secret and you have generated that 03:21.040 --> 03:25.150 token, only you are able to decrypt that token and get the information from it. 03:25.180 --> 03:30.070 Now, apart from this, once you have extracted the token and verified it, then go ahead and extract 03:30.070 --> 03:31.390 the information from the payload. 03:31.390 --> 03:33.340 That's very interesting thing comes in now. 03:33.340 --> 03:38.560 Once you have extracted this information, maybe at the time you are just grabbing the ID, then you 03:38.560 --> 03:43.840 are again making a request to the database itself, grabbing more information and putting that information 03:43.840 --> 03:44.620 somewhere. 03:44.650 --> 03:48.130 It can be anywhere into the request or whatever that is. 03:48.130 --> 03:52.360 And once that is all being done, then you make sure you don't forget the next. 03:52.360 --> 03:57.370 Now coming back onto the part, check for the token presence and extract that token. 03:57.790 --> 04:02.410 So this is where a lot of things comes up boiled based on the mobile and the web. 04:02.410 --> 04:04.180 On the web, it is super easy. 04:04.330 --> 04:06.910 You don't have to think too much majority of the time. 04:06.910 --> 04:09.400 Let me introduce you a couple of places where you can put up. 04:09.580 --> 04:10.930 Definitely there can be more. 04:10.960 --> 04:15.160 The first one is just send the token on to the front end, how that frontend guy is going to deal up, 04:15.160 --> 04:16.150 that's up to him. 04:16.150 --> 04:22.060 But we also need to make sure that information is passed on to the front end engineer that I expect 04:22.060 --> 04:27.220 that whatever the sensitive route you are trying to access, you give me that token there. 04:27.250 --> 04:29.050 This is where the cookie comes in. 04:29.050 --> 04:34.690 So majority of the time what I prefer is to set that token token in the cookie itself. 04:34.690 --> 04:38.800 And we saw that in the express that I can access the cookie directly from the backend itself. 04:38.800 --> 04:40.780 Resident Cookie So that's it. 04:40.810 --> 04:47.320 Now I prefer to use HTTP only cookie in the production because the HTTP cookie is only accessible programmatically 04:47.320 --> 04:48.100 by the backend. 04:48.100 --> 04:50.560 Only frontend cannot access this cookie. 04:50.560 --> 04:53.470 If you send just the cookie, it can be accessed by anyone. 04:53.470 --> 04:58.300 But if you just send a flag http only, it can only be accessed by the backend. 04:58.570 --> 05:01.870 Another one of the thing is you can expect that in the headers which is. 05:02.140 --> 05:07.210 A common information, so common that I can show you that in the post man itself there is a form of 05:07.210 --> 05:09.820 headers and you can just pass on this up here. 05:10.030 --> 05:14.320 And not only that, in the post we are going to see there is authorization tab and you can just go ahead 05:14.320 --> 05:17.530 and select your beta token and pass on the token here as well. 05:17.530 --> 05:20.620 So there are a lot of places where this token is supposed to go there. 05:20.650 --> 05:23.740 The reason why Postman is having this, because it is a common thing. 05:23.740 --> 05:24.910 Everybody does that. 05:24.910 --> 05:28.420 And also you can expect these tokens in the body itself. 05:28.450 --> 05:33.130 Now, one thing more I would like to add in more on to this one. 05:33.130 --> 05:35.560 Sometimes there is a strategy. 05:35.560 --> 05:40.360 Also, this is not a front end course, but just to give you more information, sometimes you will see 05:40.360 --> 05:45.790 that while sending the request you don't send any token, but there is usually a place or an important 05:45.790 --> 05:49.810 file in which you actually kind of take that request in between. 05:49.810 --> 05:55.360 Axios is completely able to intercept that request, and while sending this request just before that, 05:55.360 --> 05:57.880 you just add the token into the headers itself. 05:58.030 --> 06:02.200 Now what you are going to name this header that's totally up to you and the communication that you are 06:02.200 --> 06:02.770 making. 06:02.770 --> 06:07.720 So if you are using the bearer token, just name this as token and just add a bearer and space. 06:07.720 --> 06:12.400 And then the token you just grab that and in case you are sending it up in the header, make sure you 06:12.430 --> 06:16.120 know what you are calling this headers body is very, very rare. 06:16.120 --> 06:19.870 I haven't seen that but yes, in one and for one sensitive. 06:19.960 --> 06:25.180 Not sensitive in one of the cases I've seen that yes, it actually came into the body itself. 06:25.180 --> 06:28.750 But again, the communication is really important between you and the frontend developer. 06:28.750 --> 06:32.290 That way I do, I accept or expect my token. 06:32.500 --> 06:36.280 So this is all what we have grabbed so far as the basics. 06:36.280 --> 06:41.410 So now we know that we have a route that we need to protect and the token is playing a very important 06:41.410 --> 06:42.040 role in that. 06:42.040 --> 06:47.560 And we can place the token in the cookies, in the headers, or we can just send the token and he can 06:47.560 --> 06:49.210 make that token in the every request. 06:49.210 --> 06:51.370 So there are a lot of places to worry about. 06:51.520 --> 06:53.080 Okay, so that's the basic information. 06:53.080 --> 06:57.940 In the next video, we are going to write our own customised middleware that can actually perform this 06:57.940 --> 06:58.710 exact task. 06:58.720 --> 07:00.130 Let's catch up in the next video.