1 00:00:03,000 --> 00:00:06,145 We started writing this "login" API route, 2 00:00:06,145 --> 00:00:08,242 that accepts a POST request. 3 00:00:08,242 --> 00:00:11,163 And we've seen how we can read the data 4 00:00:11,163 --> 00:00:13,035 sent in the request body. 5 00:00:13,759 --> 00:00:15,774 Instead of logging that data, 6 00:00:15,774 --> 00:00:19,316 let's extract the "email" and "password" properties 7 00:00:19,316 --> 00:00:20,706 from the "req.body". 8 00:00:21,344 --> 00:00:24,286 And what we want to do at this point is 9 00:00:24,286 --> 00:00:27,152 send these credentials to the CMS API. 10 00:00:27,727 --> 00:00:29,356 This means we need to do 11 00:00:29,356 --> 00:00:32,139 pretty much the same thing we already did 12 00:00:32,139 --> 00:00:33,361 in the SignInPage. 13 00:00:33,996 --> 00:00:36,346 So let's copy this code from here 14 00:00:36,346 --> 00:00:39,407 and paste it into our handleLogin function. 15 00:00:39,978 --> 00:00:41,951 We'll need to import "fetchJson". 16 00:00:42,811 --> 00:00:45,343 And also make this function "async", 17 00:00:45,343 --> 00:00:47,241 because we're using "await" 18 00:00:47,241 --> 00:00:50,475 to unpack the Promise returned by "fetchJson". 19 00:00:51,115 --> 00:00:53,814 Now, what do we do with this response? 20 00:00:53,814 --> 00:00:55,661 Let's start by logging it. 21 00:00:55,661 --> 00:00:57,791 So this is the "CMS response". 22 00:00:58,781 --> 00:01:01,489 Let's try calling our API route now. 23 00:01:02,247 --> 00:01:03,750 We still get "200 OK" 24 00:01:03,750 --> 00:01:06,756 with an empty JSON object in the response. 25 00:01:07,328 --> 00:01:09,039 But if we look at the logs 26 00:01:09,039 --> 00:01:11,474 we can tell that it did call the CMS, 27 00:01:12,040 --> 00:01:13,917 and it received a response 28 00:01:13,917 --> 00:01:17,599 containing the JSON web token and the user details. 29 00:01:18,172 --> 00:01:20,421 So we could use that data to return 30 00:01:20,421 --> 00:01:23,120 something more useful in our own response. 31 00:01:23,685 --> 00:01:26,975 We know that the CMS response will contain 32 00:01:26,975 --> 00:01:29,873 the "jwt" string and a "user" object. 33 00:01:30,452 --> 00:01:32,007 No need to log this any more. 34 00:01:32,507 --> 00:01:34,984 Rather, we want to return something 35 00:01:34,984 --> 00:01:36,471 in our JSON response. 36 00:01:36,471 --> 00:01:39,374 Now, we don't want to put the token here, 37 00:01:39,374 --> 00:01:42,701 because we said we should set that as a cookie, 38 00:01:42,701 --> 00:01:45,179 and we'll see how to do that later. 39 00:01:45,179 --> 00:01:47,869 But we could return some user details. 40 00:01:47,869 --> 00:01:49,569 And we could select only 41 00:01:49,569 --> 00:01:51,834 the properties we actually need, 42 00:01:51,834 --> 00:01:54,949 instead of passing the entire "user" object. 43 00:01:56,016 --> 00:01:58,011 So we could pass the "id", 44 00:01:58,011 --> 00:01:59,700 that is the "user.id", 45 00:02:00,277 --> 00:02:02,293 and maybe the name of the user, 46 00:02:02,293 --> 00:02:05,024 in case we want to display that on the UI. 47 00:02:05,590 --> 00:02:06,847 In the CMS response 48 00:02:06,847 --> 00:02:08,833 this is called the "username". 49 00:02:09,400 --> 00:02:12,297 But we can rename properties as we see fit 50 00:02:12,297 --> 00:02:13,677 in our own response. 51 00:02:14,246 --> 00:02:16,552 Now, let's try sending another request. 52 00:02:17,379 --> 00:02:19,185 This time it doesn't log anything, 53 00:02:19,685 --> 00:02:21,198 but the response body 54 00:02:21,198 --> 00:02:24,512 contains the user details we're interested in, 55 00:02:24,512 --> 00:02:26,242 that is "id" and "name". 56 00:02:26,242 --> 00:02:29,628 And their values are those coming from the CMS. 57 00:02:30,345 --> 00:02:31,984 Ok. So far so good. 58 00:02:32,484 --> 00:02:35,794 Now, what happens if we send the wrong password? 59 00:02:36,450 --> 00:02:40,528 In this case we get a "500 Internal Server Error", 60 00:02:41,028 --> 00:02:42,700 and if we check the logs 61 00:02:42,700 --> 00:02:45,905 that's because "fetchJson" throws an ApiError, 62 00:02:46,475 --> 00:02:48,754 which is the custom error we defined, 63 00:02:48,754 --> 00:02:49,924 so that's expected. 64 00:02:50,641 --> 00:02:53,469 But we need to handle this scenario 65 00:02:53,469 --> 00:02:55,004 in our API handler, 66 00:02:55,004 --> 00:02:56,863 by catching any errors. 67 00:02:59,041 --> 00:03:01,714 And in this case we could return 68 00:03:01,714 --> 00:03:04,722 a more appropriate HTTP status code, 69 00:03:04,722 --> 00:03:08,064 like 401 that stands for "Unauthorized". 70 00:03:08,732 --> 00:03:10,977 Because it's not a "Server Error" 71 00:03:10,977 --> 00:03:13,630 if the user entered the wrong password. 72 00:03:13,630 --> 00:03:16,895 Again, keep in mind that I'm treating all errors 73 00:03:16,895 --> 00:03:20,229 in the same way here, just to keep things simple. 74 00:03:20,229 --> 00:03:22,406 But it would be better to handle 75 00:03:22,406 --> 00:03:25,535 network errors for example in a different way. 76 00:03:26,376 --> 00:03:29,819 Anyway, if we go and test our login request again, 77 00:03:30,676 --> 00:03:34,421 this time we get a "401 Unauthorized" response. 78 00:03:34,921 --> 00:03:37,454 So this is what will tell the client 79 00:03:37,454 --> 00:03:39,846 that the credentials were invalid. 80 00:03:40,521 --> 00:03:43,049 Now, what we're still missing here is 81 00:03:43,049 --> 00:03:45,235 what was our original reason for 82 00:03:45,235 --> 00:03:48,105 writing this API route in the first place, 83 00:03:48,742 --> 00:03:50,404 that is setting a cookie 84 00:03:50,404 --> 00:03:52,483 containing the JSON web token. 85 00:03:53,053 --> 00:03:55,160 And we'll take care of that in the next video.