1 00:00:02,050 --> 00:00:03,190 Onto our next test. 2 00:00:03,190 --> 00:00:08,450 So we want to make sure that we can only access this root handler if the user is actually signed in. 3 00:00:08,470 --> 00:00:13,160 Let's first just create a test for this and we'll worry about the actual implementation. 4 00:00:13,270 --> 00:00:19,360 So I'm going to put in a body to this thing I'm going to try to make a request over 5 00:00:24,240 --> 00:00:25,440 to my app. 6 00:00:25,650 --> 00:00:28,360 I again want to make a POST request to API tickets. 7 00:00:28,890 --> 00:00:35,460 And again I'm going to send in an empty object so in the scenario right here we are not authenticated 8 00:00:35,490 --> 00:00:36,390 in any way. 9 00:00:36,390 --> 00:00:41,970 We are not sending this request with any kind of status code or some kind of cookie Jason web token 10 00:00:42,090 --> 00:00:43,580 or anything like that. 11 00:00:43,590 --> 00:00:47,910 So if we just send this right here this is going to stimulate us making a request to the threat handler 12 00:00:48,180 --> 00:00:55,170 as if we were not signed in so we need to now look at that response and make sure that it has a status 13 00:00:55,170 --> 00:00:58,440 code that is somehow telling us that we are not correctly authenticated. 14 00:00:58,650 --> 00:01:02,670 That means we're going to have to get a quick reminder on what happens when we make a request that we 15 00:01:02,670 --> 00:01:08,910 are essentially not authenticated to make it's going to go back over to my common library. 16 00:01:09,000 --> 00:01:13,980 Inside there I'll find the heirs directory and you might recall that a while ago back when we were working 17 00:01:13,980 --> 00:01:18,740 on the off service we put together a custom air called not authorized air. 18 00:01:18,780 --> 00:01:23,220 This was the air that we would throw whenever a user tried to make a request or a root handler that 19 00:01:23,220 --> 00:01:28,090 they were not allowed to make request to so if we tried to make a request to a handler if they were 20 00:01:28,090 --> 00:01:34,910 not authorized to access we should be getting back a status code for a one to back inside this test. 21 00:01:34,950 --> 00:01:38,700 We can either take a look at the response and write out something very similar to what we wrote out 22 00:01:38,700 --> 00:01:39,240 up here. 23 00:01:39,330 --> 00:01:45,720 So in other words we could say expect response status to equal for a one because in this case we want 24 00:01:45,720 --> 00:01:50,790 to make sure that are not authenticated requests gets rejected or alternatively we could just chain 25 00:01:50,790 --> 00:01:57,240 on an expect statement to the request itself of for a one if we do that we do not need to get access 26 00:01:57,240 --> 00:02:04,040 to the response itself or write out the separate expectation. 27 00:02:04,170 --> 00:02:10,110 Let's save this and go back over to my terminal again and I'll see that that second test is failing 28 00:02:11,400 --> 00:02:16,530 so we expected or we want to see that we got a four a one but we actually got through to our root handler 29 00:02:16,590 --> 00:02:18,390 with a status code up to 100. 30 00:02:18,390 --> 00:02:23,250 Coming back to us that means that right now we do not have any idea of authentication being tied to 31 00:02:23,250 --> 00:02:24,300 this drought handler. 32 00:02:24,390 --> 00:02:26,300 So we need to now go into our implementation. 33 00:02:26,320 --> 00:02:30,640 We need to make sure we add something in to say hey at the user is not authenticated. 34 00:02:30,690 --> 00:02:32,260 Get them out of here. 35 00:02:32,280 --> 00:02:33,690 So how are we gonna do that. 36 00:02:33,690 --> 00:02:39,030 Well once again you might recall that when we were working on our auth service we kind of thought ahead 37 00:02:39,180 --> 00:02:43,950 and we realized that at some point time we've probably need some middleware to detect whether or not 38 00:02:43,950 --> 00:02:46,090 the user was actually authenticated. 39 00:02:46,380 --> 00:02:51,180 And to that end we put together two different middleware as we put together a middleware called current 40 00:02:51,180 --> 00:02:52,270 user. 41 00:02:52,260 --> 00:02:55,000 So I'm inside of my common module right now. 42 00:02:55,020 --> 00:02:56,820 Here's the current user middleware. 43 00:02:56,820 --> 00:03:01,800 The whole goal of this thing was to take a look at the incoming requests session property and see if 44 00:03:01,800 --> 00:03:03,600 there's a Jason web token there. 45 00:03:03,870 --> 00:03:06,620 If there wasn't a token we just called next. 46 00:03:06,630 --> 00:03:12,390 Otherwise if there was we attempted to decode the token and then set it on the current user property 47 00:03:13,450 --> 00:03:18,090 with the current user middleware it was just about defining that wrecked current user property. 48 00:03:18,150 --> 00:03:18,570 That was it. 49 00:03:18,600 --> 00:03:23,220 That's all we cared about with this thing the other middleware that we put together was required. 50 00:03:23,250 --> 00:03:27,800 OK so gonna open that up really quick require off middleware. 51 00:03:27,800 --> 00:03:32,780 It's going to take a look at that current user property and if it is not defined we're gonna throw a 52 00:03:32,780 --> 00:03:38,640 not authorized air so all we really have to do to implement some level of authentication protection 53 00:03:38,640 --> 00:03:44,070 around our right handler is wire up both the current user middleware and the require off middleware 54 00:03:44,100 --> 00:03:48,210 as well as pretty much it. 55 00:03:48,220 --> 00:03:50,980 So where are we going to actually wire these things up. 56 00:03:50,980 --> 00:03:56,270 Well every single request that comes into our application if the user is authenticated or has a J somewhere 57 00:03:56,320 --> 00:03:57,990 token we probably want to do that. 58 00:03:58,120 --> 00:04:04,120 Current user lookup so inside of our app dot TSA file we're going to import that current user middleware 59 00:04:04,120 --> 00:04:10,000 inside of here and wired up to our app so that every single incoming request is going to have that look 60 00:04:10,000 --> 00:04:15,190 up and see whether or not the user is authenticated but if the user is not authenticated we don't necessarily 61 00:04:15,190 --> 00:04:16,960 want to immediately reject them. 62 00:04:16,960 --> 00:04:22,010 Instead we only want to reject requests that are coming into a very specific route handlers. 63 00:04:22,030 --> 00:04:27,550 So for example if someone is trying to look up a list of all tickets or look up a very specific ticket 64 00:04:27,610 --> 00:04:31,240 we probably don't want to make someone be authenticated for that. 65 00:04:31,270 --> 00:04:35,890 So I don't really want to require authentication on these two root handlers but in order to make a post 66 00:04:35,890 --> 00:04:41,680 to create a ticket or to update a ticket I probably do so only some route handlers need to have that 67 00:04:41,680 --> 00:04:43,810 require auth middleware wired up. 68 00:04:43,810 --> 00:04:46,420 So long story short here's what we're going to do inside of app. 69 00:04:46,450 --> 00:04:53,350 Yes I'm going to find my common module import and I'll add on the current user middleware I'll then 70 00:04:53,350 --> 00:05:01,060 connect that to my application down here apt use different user make sure you add that middleware after 71 00:05:01,090 --> 00:05:03,850 Cookie session cookie session has to run first. 72 00:05:03,850 --> 00:05:07,450 So can take a look at the cookie and set the record session property. 73 00:05:07,450 --> 00:05:12,070 If we don't do that then whenever current user runs it will be running too soon and wrecked out session 74 00:05:12,070 --> 00:05:19,360 will not be set so now if the user is authenticated that will set the record current user property. 75 00:05:19,360 --> 00:05:24,790 And now we can go over to our actual root handler so inside of roots new dot. 76 00:05:24,800 --> 00:05:25,520 Yes. 77 00:05:25,570 --> 00:05:30,760 And this is where we will apply some actual authentication protection and make sure that the user is 78 00:05:30,790 --> 00:05:32,290 authenticated. 79 00:05:32,290 --> 00:05:41,010 So at the very top this is where we will import the require auth middleware from my common module and 80 00:05:41,010 --> 00:05:48,560 I will apply that as a middleware inside my root handler the require off like so. 81 00:05:48,780 --> 00:05:51,840 Let's save that way back over. 82 00:05:52,170 --> 00:05:53,880 And now that test is passing 83 00:05:57,000 --> 00:06:02,560 go now I just kind of realized we should probably write out a test that kind of checks for the opposite. 84 00:06:02,560 --> 00:06:07,270 So if we want to write our test to make sure this thing can only be used if the user is signed in we 85 00:06:07,270 --> 00:06:12,520 probably should have a test that says if the user is signed in we should not return a status code of 86 00:06:12,520 --> 00:06:13,430 400. 87 00:06:13,450 --> 00:06:19,000 I think that makes it a little bit of sense because right now we could be signed in and who knows maybe 88 00:06:19,040 --> 00:06:21,030 at the request handler still isn't working correctly. 89 00:06:21,040 --> 00:06:24,920 So we should probably just write out a test to make sure that's working as expected. 90 00:06:24,930 --> 00:06:29,900 It's gonna put in another test right here and I'll say the user. 91 00:06:29,920 --> 00:06:38,730 How about returns a status other than for one if the user is signed in 92 00:06:44,960 --> 00:06:48,630 then to write out this test we can do something very similar to what we did back up here. 93 00:06:48,650 --> 00:06:54,580 So in this case we need to make sure that the status code is not equal to a 4 1 Don't let's write out 94 00:06:54,640 --> 00:06:55,510 a test for that. 95 00:06:55,510 --> 00:07:05,010 So we'll do a concert response is a wait request to app I'm gonna make a post to API tickets I will 96 00:07:05,010 --> 00:07:16,720 send an empty object and we'll do it and expect response not status not two equal or one. 97 00:07:16,750 --> 00:07:17,100 All right. 98 00:07:17,110 --> 00:07:23,050 Now if I put back over I will see an error around that test it looks like that new test is failing entirely. 99 00:07:23,050 --> 00:07:27,130 The reason that is failing is because well we are still making a request right here that is not authenticated 100 00:07:27,250 --> 00:07:28,480 in any way. 101 00:07:28,480 --> 00:07:33,520 So we need to figure out some method or some methodology to make an authenticated request inside of 102 00:07:33,520 --> 00:07:34,910 our test environment. 103 00:07:34,990 --> 00:07:39,730 You might recall that we've put together our test suite back inside the service we had put together 104 00:07:39,730 --> 00:07:44,590 inside of our setup dot t s file that global sign in function right here. 105 00:07:44,620 --> 00:07:51,260 So I'm at the bottom of our setup dot t s file we put this thing together over here and unfortunately 106 00:07:51,260 --> 00:07:54,390 this thing is only going to work correctly inside of our service. 107 00:07:54,410 --> 00:07:56,080 This video is running a little bit long however. 108 00:07:56,090 --> 00:07:57,340 So let's take a pause right here. 109 00:07:57,380 --> 00:08:00,710 We come back in the next video I'm going to explain to you why this thing will only work in the out 110 00:08:00,710 --> 00:08:04,160 service and then start to fix it up so we can use it over here inside of tickets.