WEBVTT 00:00.080 --> 00:00.320 Okay. 00:00.320 --> 00:06.320 So we have the ability to apply authentication to our routes directly inside of the auth app. 00:06.320 --> 00:13.460 Right now, however, I want to be able to add authentication to our reservations controller so that 00:13.460 --> 00:20.660 any of these routes here will be protected by a JWT auth guard and the user must be authenticated to 00:20.660 --> 00:21.800 access these routes. 00:21.800 --> 00:28.160 So in order to do this, we need to have a way to connect our microservices together so that the reservations 00:28.160 --> 00:31.820 can talk to auth and authenticate a user. 00:31.850 --> 00:37.700 Nestjs offers this out of the box with a number of different transport options to support networking 00:37.700 --> 00:39.290 between our microservices. 00:39.320 --> 00:46.580 We're going to use a standard TCP based transport layer to be able to connect our microservices together. 00:46.580 --> 00:52.250 So let's go ahead and start wiring up our auth service to be able to talk as a microservice. 00:52.250 --> 00:58.760 Firstly, we're going to go back into the terminal and we're going to go ahead and install nestjs, 00:58.760 --> 01:06.080 slash microservices so we can go ahead and start our server back up by running Docker, compose up here 01:06.080 --> 01:12.890 and now inside of our auth service, we're going to convert this into a hybrid application, one that 01:12.890 --> 01:20.030 listens for both incoming Http connections in our controllers as well as over our microservice layer 01:20.030 --> 01:20.900 through TCP. 01:20.900 --> 01:27.650 So in order to accomplish this in our main.ts, we're going to go ahead and call app dot connect microservice, 01:27.650 --> 01:34.100 which will allow us to specify an options object here where we can specify the transport that we want. 01:34.100 --> 01:38.480 So like I said before, there are a number of different transport options available, including Redis, 01:38.510 --> 01:44.420 Rabbitmq and Kafka, which I have covered in past videos and I may add to this course as well. 01:44.450 --> 01:50.690 However, for now we're going to make use of just a standard TCP protocol so we can set this with the 01:50.690 --> 01:56.570 transport from Nestjs microservices, and this is all the different transport layers. 01:56.570 --> 02:00.690 As I mentioned, we're going to choose TCP, which is the default out of the box. 02:00.690 --> 02:07.140 So now that we've connected a microservice here, as well as calling App.listen on our port for Http 02:07.140 --> 02:13.260 connections, we're going to call await app dot, start all microservices to start our microservice 02:13.260 --> 02:18.270 up over this TCP transport layer and listen for incoming events and requests. 02:18.270 --> 02:23.820 So if we go back in our terminal here, we should see the auth service start back up in addition to 02:23.820 --> 02:30.060 the Nest app starting up successfully here, we can also see that the nest microservice started successfully 02:30.060 --> 02:33.000 here in our logger for sleep sleeper auth. 02:33.000 --> 02:36.210 Now we're actually ready to talk to this auth microservice. 02:36.210 --> 02:42.750 So now that our auth service is listening for incoming TCP connections in our microservice architecture, 02:42.750 --> 02:49.830 I want to go ahead and create a new common auth guard that all of our services can utilize to check 02:49.830 --> 02:53.610 to see if a JWT passed to them is valid. 02:53.610 --> 02:59.730 So what it's going to do in that auth guard is it's going to reach out and make a call to our auth service 02:59.730 --> 03:04.080 through TCP and determine if the provided JWT is indeed valid. 03:04.110 --> 03:07.200 If it's valid, we will return the user. 03:07.200 --> 03:13.470 I want to actually put this off guard into our Libs common folder because I want to use it in all of 03:13.470 --> 03:14.820 our different microservices. 03:14.820 --> 03:21.030 It'll be the same guard, the same way to authenticate for all Http routes outside of the auth service. 03:21.030 --> 03:24.390 So let's go ahead and create a new auth folder. 03:24.390 --> 03:33.000 I'll go ahead and create firstly an index.ts and make sure that we export everything from this off folder. 03:33.000 --> 03:37.920 And now in here I'm going to go ahead and create a new JWT auth guard. 03:37.920 --> 03:44.640 So this is going to be an injectable class here and we'll export the class JWT auth guard, which is 03:44.640 --> 03:49.140 going to implement the can activate interface from Nestjs Common. 03:49.140 --> 03:56.640 Then I'll go inside of the Index.ts here and export everything from the auth guard that we just created. 03:56.640 --> 04:00.720 So we're complaining that because we're not implementing the can activate method here. 04:00.720 --> 04:03.420 So let's go ahead and actually implement this. 04:03.420 --> 04:10.410 So remember this JWT auth guard is going to be sitting in front of any of our public facing API routes. 04:10.440 --> 04:16.890 It's going to expect to be passed a JWT cookie in order to authenticate past it. 04:16.890 --> 04:21.480 So we're going to create a new variable here called JWT and set it equal to context. 04:21.480 --> 04:28.650 Switch to Http, get request to get us the current in-flight request object for this route. 04:28.650 --> 04:33.630 And then inside of there, we're going to look for the cookies object, which the cookie parser library 04:33.630 --> 04:36.090 is responsible for creating and populating. 04:36.090 --> 04:43.770 So any service that actually implements or uses this off guard will have to use the cookie parser library 04:43.770 --> 04:47.640 to make sure we get the authentication cookie properly set on here. 04:47.640 --> 04:53.490 So we'll pull that authentication cookie off of this object so we can do a quick check here to see if 04:53.490 --> 04:59.850 we don't have a JWT provided by the user, we will simply return false returning a boolean false. 05:00.000 --> 05:03.930 From this guard here will not allow the current request to proceed. 05:03.930 --> 05:09.390 So now we need to actually reach out to our auth microservice to determine if this JWT is valid and 05:09.390 --> 05:11.190 get the associated user. 05:11.190 --> 05:18.510 So we're going to assume that any any service that uses this JWT auth guard is also going to have a 05:18.510 --> 05:25.680 client proxy available to inject for this auth service, which is how we talk to other microservices 05:25.680 --> 05:27.840 in this nestjs architecture. 05:27.840 --> 05:30.030 So let's see how this actually looks like. 05:30.030 --> 05:35.370 We use the inject keyword here to actually be able to inject this client proxy. 05:35.370 --> 05:40.440 And right now we don't actually have this injection token defined for the auth service yet. 05:40.440 --> 05:43.430 So let's go ahead and do that in the common folder. 05:43.440 --> 05:47.700 We'll go ahead and create a new constants directory. 05:48.750 --> 05:55.110 And inside here we'll create a new file called Services Dot TS, and we'll just simply export a const 05:55.110 --> 05:59.510 here called auth service, which is just going to be called Auth. 05:59.520 --> 06:02.890 So now that we have this constant defined, let's actually use it in here. 06:02.890 --> 06:10.270 We'll import the auth service and this is going to be a private read only auth client of type client 06:10.270 --> 06:17.290 proxy from Nestjs microservices, which is the object that will allow us to communicate to our other 06:17.290 --> 06:21.670 microservices via the provided transport layer. 06:21.670 --> 06:27.280 So now that we actually have the auth client here that we can use to talk to the auth service, we need 06:27.280 --> 06:33.550 to actually set up a route in our authservice that is set up to be able to receive RPC calls. 06:33.550 --> 06:39.880 And in order to do that we'll go into our auth app, into the auth dot controller here and we're going 06:39.880 --> 06:49.150 to add a new route in this controller and it's going to use the message pattern decorator from Nestjs 06:49.150 --> 06:55.750 microservices, which is going to allow us to accept incoming RPC calls on our chosen transport layer. 06:55.750 --> 07:01.270 So this is going to be very similar to our Http call here for post where we provide the route name. 07:01.270 --> 07:04.270 In this case, we're going to provide the message pattern name. 07:04.270 --> 07:07.000 In this case, I'm going to call it authenticate. 07:07.330 --> 07:13.840 So this is what we're going to use to actually authenticate our JWT and I'll call this method async 07:13.870 --> 07:14.860 authenticate. 07:14.860 --> 07:21.520 So in this authenticate route, all I want to do is actually just run it through our existing JWT auth 07:21.520 --> 07:22.120 guard. 07:22.120 --> 07:26.170 We'll have to modify it a bit, but it'll use the same logic. 07:26.200 --> 07:31.810 We want to check in incoming JWT, verify that it's correct and return a user that's associated with 07:31.810 --> 07:40.330 it, which is all logic we've already set up in our JWT strategy over here where we are currently extracting 07:40.330 --> 07:42.700 the JWT from the request object here. 07:42.700 --> 07:45.370 So let's go ahead and apply this auth guard. 07:45.400 --> 07:51.460 The JWT auth, guard, guard still work just the same in microservices, so we can be sure that our 07:51.460 --> 07:54.370 request will still be routed through the JWT auth guard. 07:54.370 --> 08:01.240 So let's go inside our JWT auth guard which of course we know it actually implements the strategy here. 08:01.240 --> 08:08.920 Right now we are pulling the JWT off of the request header in the cookies object here. 08:08.920 --> 08:15.190 However, when the JWT is coming in from our RPC call in our JWT off guard, it's not going to be inside 08:15.190 --> 08:16.300 of a cookies object. 08:16.300 --> 08:19.180 It's just going to be under the straight request object. 08:19.180 --> 08:25.120 So we can put in a bit of logic here to say if there is no request cookie, we can then check to see 08:25.120 --> 08:31.660 if the authentication key actually exists on the request object itself here. 08:31.660 --> 08:38.050 And we're also going to change the type here to be any because this can be a request from Express or 08:38.050 --> 08:40.300 from an RPC call. 08:40.330 --> 08:40.750 Okay. 08:40.750 --> 08:48.040 So now that we have set up a message pattern for this authentication flow, let's go back into our auth 08:48.040 --> 08:53.170 guard and we're actually going to make this call using the auth client. 08:53.170 --> 09:00.070 So what we're going to do here is we're going to call this dot auth client dot send, and this is going 09:00.070 --> 09:05.560 to send a message to the auth service that matches the current pattern. 09:05.560 --> 09:10.600 And right now, of course we know the pattern we want to target is the authenticate message pattern 09:10.600 --> 09:11.680 that we just created. 09:11.680 --> 09:17.350 And next we have the data object, which is going to be the data that we send in this call and we know 09:17.350 --> 09:20.230 we need to add the authentication key here. 09:20.230 --> 09:26.320 And this value here is going to be the JWT that we've already extracted from the incoming cookies body. 09:26.320 --> 09:32.200 So we're actually going to go ahead and return this observable altogether, which is a valid return 09:32.200 --> 09:39.490 type here of observable boolean, and we're going to pipe in additional operators onto this observable. 09:39.490 --> 09:46.180 The first operator is going to be the tap operator, which of course we are importing from Rxjs, which 09:46.180 --> 09:52.450 is going to allow us to execute a side effect on the incoming response And the incoming response from 09:52.450 --> 09:58.180 the auth service will eventually be the user itself that is associated with this JWT. 09:58.180 --> 09:59.590 So what I want to do is I want to. 09:59.650 --> 10:03.720 Take that user and add it to the current request object. 10:03.730 --> 10:12.760 So to do this we are going to call context dot switch to Http get request here and then we are going 10:12.760 --> 10:16.390 to set the user object on the request equal to the response. 10:16.390 --> 10:20.410 We get back from the auth service, which will be the user itself. 10:20.410 --> 10:25.210 We'll use the map operator from the Rxjs package and return. 10:25.210 --> 10:25.930 True. 10:25.930 --> 10:31.690 If we have a successful response back from the auth microservice, meaning we are authenticated, we 10:31.690 --> 10:36.850 want to return true from a can activate which will allow the request to proceed and make sure we're 10:36.850 --> 10:37.720 authenticated. 10:37.720 --> 10:44.350 We're ready to integrate our newly created common JWT auth guard into our reservations routes to lock 10:44.350 --> 10:47.470 them down to only authenticated users. 10:47.470 --> 10:53.290 So we'll open up our reservations controller and start with a post route right here. 10:53.320 --> 11:02.750 We will use the use guard's decorator here and import the JWT auth guard and we can see it's directing 11:02.750 --> 11:08.840 us to the common folder here and we'll change the path directly by targeting app slash common. 11:08.840 --> 11:14.510 So now we're getting an error from the reservations app that we can't resolve the dependencies of the 11:14.510 --> 11:21.500 auth guard, which makes total sense because we haven't actually provided the auth service injection 11:21.500 --> 11:26.510 token here in the reservation service where we're trying to use it. 11:26.510 --> 11:33.410 So we'll go ahead and take care of that now in the Reservations module and to actually register this 11:33.410 --> 11:41.150 service and provide this injection token, we're going to use the clients module dot register call here 11:41.150 --> 11:44.120 where we're going to pass in the injection token. 11:44.120 --> 11:51.560 In this case, we know, of course, it's the auth service which will import up top from App Common 11:51.560 --> 11:54.620 and we can add to this existing import here. 11:54.620 --> 11:59.300 So we'll import the auth service and we can see we're not actually exporting it right now. 11:59.300 --> 12:08.480 So let's go ahead and change that out by adding a index.ts in our constants directory here and then 12:08.480 --> 12:16.130 we'll just export everything from the services file now and in this route in Index.ts, we'll of course 12:16.130 --> 12:22.880 need to export everything from the constants directory and now we should be able to import properly. 12:22.880 --> 12:29.060 So we have this auth service for providing and we need to specify the transport layer, which of course 12:29.060 --> 12:31.700 we know is going to be at the TCP layer. 12:31.700 --> 12:37.040 So now if we go back to the terminal, we can see the reservation service is finally starting up, just 12:37.040 --> 12:42.920 like we've done in the auth service where in the Main.ts we're using cookie parser here to parse our 12:42.920 --> 12:46.490 incoming cookies and add them to the incoming request object. 12:46.520 --> 12:54.320 We'll do the same thing in our main.ts for the Reservations app here and I will similarly copy over 12:54.320 --> 12:57.650 the import itself for cookie parser. 12:57.680 --> 12:59.150 Okay, so back in Postman. 12:59.150 --> 13:07.190 Now if we send a request to localhost 3001 slash auth slash login with our email and password for a 13:07.190 --> 13:10.760 user we've already created and we send this post request off. 13:10.760 --> 13:15.800 We are authenticated and of course we get this JWT cookie set. 13:15.800 --> 13:24.860 So now we should be able to send a request to localhost 3000 slash reservations and post a new reservation. 13:24.860 --> 13:29.390 So let's go ahead and send a sample request and you can see immediately we're getting a status code 13:29.390 --> 13:31.730 500 internal server error. 13:31.760 --> 13:37.940 We can actually see in the logs here for our Reservations app that we're having an error during our 13:37.940 --> 13:38.690 request. 13:38.690 --> 13:46.850 And the error here is that the TCP connection is actually closed and was never actually created between 13:46.850 --> 13:49.400 our Reservations app and our auth service. 13:49.400 --> 13:52.700 So there's some issue communicating between the two services. 13:52.730 --> 13:58.850 And the issue that we're having right now is in our Main.ts for our auth service. 13:58.880 --> 14:05.660 We haven't specified the host and port that we want to be listening on for our TCP microservice here. 14:05.660 --> 14:09.650 So I'm going to have a new options object here where we do just that. 14:09.650 --> 14:19.130 Our hosts property here is going to specify the 0.0.0.0 IP address, which tells the microservice to 14:19.130 --> 14:22.520 bind to all interfaces on the host. 14:22.520 --> 14:28.460 And then for the port here, we want to actually extract this from the environment. 14:28.460 --> 14:35.570 So let's get the config service out of the app up here before we connect the microservice for the port 14:35.570 --> 14:44.150 here, we'll call config service dot get and we'll call this environment variable TCP port. 14:44.150 --> 14:51.740 And I'll also change the port variable for our Http server and call this Http port just so we're a bit 14:51.740 --> 14:53.780 more descriptive about these ports. 14:53.780 --> 14:56.960 And then we're going to go into the auth module and change our validation. 14:56.960 --> 14:59.030 We'll say that this port should now be. 14:59.660 --> 15:03.260 Port, which is a number as well as adding a new one here. 15:03.260 --> 15:07.190 So we can add the TCP port, which will also be a number. 15:07.190 --> 15:14.750 So finally we'll have to go to our EMF here for the auth service and change the Http port to be 3001. 15:14.750 --> 15:20.710 And then I'll add a new environment variable, the TCP port, and I'll set this to 3002. 15:20.720 --> 15:29.870 So now in the main.ts we are pulling the TCP port for our port and we're binding this microservice to 15:29.870 --> 15:34.700 all public interfaces on our host so that we can listen for incoming requests. 15:34.700 --> 15:41.420 So now that we've set the options for the auth microservice itself, we need to go into the reservations 15:41.420 --> 15:48.740 module and specify these options in a new options object here for the auth service, where we will of 15:48.740 --> 15:51.500 course specify the host and port. 15:51.530 --> 15:57.440 Now we want to be able to use a config service to get the host and port in our client module registration 15:57.440 --> 15:57.920 here. 15:57.920 --> 16:05.610 So to do this we'll actually copy the existing object we have and instead of calling register on clients 16:05.610 --> 16:13.320 module, we can also call the register async version here that's going to allow us to use a use factory. 16:13.320 --> 16:19.860 So to actually configure this register async, we're going to provide an array here where each entry 16:19.860 --> 16:22.020 in the array is a different client. 16:22.020 --> 16:28.500 So we'll go ahead and provide a single entry here where we have the name property, which we're going 16:28.500 --> 16:31.140 to keep as the auth service. 16:31.140 --> 16:33.210 So this is still the injection token. 16:33.210 --> 16:39.720 And then we have the use factory here, which is going to allow us to inject the config service from 16:39.720 --> 16:46.740 Nestjs config where we're going to return the original options object, where of course we have the 16:46.740 --> 16:54.120 transport layer we know will be transport dot TCP and then we have the options object here where we 16:54.120 --> 17:03.570 will specify the host which we're going to pull off the config service dot, get auth host and then 17:03.570 --> 17:09.540 we'll have the port as well which will be set to config service dot get auth port. 17:09.570 --> 17:15.870 So we now need to go into our env for the reservations app and provide these environment variables. 17:15.870 --> 17:22.560 So the auth host is going to be actually defined in the Docker compose here in Docker, these services 17:22.560 --> 17:27.210 can talk to each other by the actual names of the services we defined here. 17:27.210 --> 17:32.970 So the host name for auth will just be auth and the host name for reservations is just reservations 17:32.970 --> 17:34.260 running in Docker. 17:34.260 --> 17:38.310 So we will set the auth host here to just be auth. 17:38.850 --> 17:46.560 And then we know of course that the auth port here will be 3002, which is corresponds to the TCP port 17:46.590 --> 17:48.990 we defined in the auth service. 17:48.990 --> 17:50.940 So we'll set this to 3002. 17:50.940 --> 17:58.020 So finally make sure that we actually provide the inject property here or we go ahead and inject the 17:58.020 --> 18:00.020 config service as well. 18:00.030 --> 18:00.330 Okay. 18:00.330 --> 18:06.810 So back in Postman, I'll go ahead and launch another request localhost 3001 all slash login with a 18:06.810 --> 18:13.800 valid user so that I have a JWT cookie set and then we'll go back to localhost 3000 slash reservations 18:13.800 --> 18:17.280 to create a reservation and we get an internal server error. 18:17.280 --> 18:22.860 So if we take a look now you can see we're erroring out because we have an rxjs error. 18:22.890 --> 18:28.800 No elements in sequence, which really means that we're just not returning anything from our observable, 18:28.800 --> 18:34.680 which we know makes sense because right now inside of our auth controller for the message pattern, 18:34.680 --> 18:36.960 we're not actually returning anything right now. 18:36.960 --> 18:42.930 So let's go ahead and firstly take a look at the strategy itself When we're sending this request because 18:42.930 --> 18:49.380 I want to see that the JWT auth guard here is actually sending the JWT correctly. 18:49.380 --> 18:56.640 So let's go ahead and see that by going to the JWT strategy and instead of returning the straight authentication 18:56.640 --> 19:05.730 here, let's open this up as a function body here where we are going to return the original statement. 19:05.730 --> 19:12.090 But then I just want to log out the incoming request so that we can see it inside of this JWT strategy. 19:12.090 --> 19:15.630 So now if I send a request, we still get this error. 19:15.630 --> 19:21.540 However, if we go up in the auth service, we can now see that we're actually logging out the request 19:21.540 --> 19:22.830 in the strategy. 19:22.830 --> 19:29.610 And you can see importantly, we have this authentication property set on the incoming request or in 19:29.610 --> 19:30.960 this case data object. 19:30.960 --> 19:37.650 And this matches exactly an auth guard, the object that we're sending to this message pattern controller. 19:37.650 --> 19:39.540 So the JWT looks correct. 19:39.540 --> 19:42.180 Let's go ahead and back in the strategy. 19:42.180 --> 19:43.290 We'll undo this here. 19:43.290 --> 19:47.850 And and so I've gone ahead and just returned the straight authentication keyword here. 19:47.850 --> 19:53.430 Now that we know we're getting the JWT correctly, let's go into the auth controller and we're going 19:53.430 --> 19:59.340 to use the ad payload decorator here from Nestjs Microservices. 19:59.630 --> 20:07.040 Which will extract the current payload for this message pattern, which is the same exact request object 20:07.040 --> 20:09.860 here that the JWT strategy receives. 20:09.860 --> 20:14.870 So we can actually get this object in the route controller with the payload decorator. 20:14.900 --> 20:21.920 We'll call this data of type any and let's just console dot log the data now. 20:21.950 --> 20:29.690 So after we've run through the Jdbc strategy and we've set the user on the data object or the request 20:29.690 --> 20:34.490 object here, we should now see that user in this payload object. 20:34.490 --> 20:40.550 So let's go ahead and actually verify that if we send the postman call again, we'll see in the logs. 20:40.550 --> 20:47.030 Now if we scroll up to the auth service where we can actually see the data object being outputted. 20:47.030 --> 20:56.060 And of course now we see the user object which the JWT strategy added for us after it authenticated 20:56.060 --> 20:59.670 the JWT and got the user from the user service. 20:59.670 --> 21:05.310 So now we can simply return the data dot user back to the caller here. 21:05.310 --> 21:11.340 So now if we send off a request, we can see we have finally succeeded in sending a request, although 21:11.340 --> 21:15.630 now it's just malformed because we don't have the correct Json body. 21:15.630 --> 21:22.470 We are indeed passing our JWT auth guard and we are correctly authenticating against this route. 21:22.470 --> 21:28.380 So one thing I want to do before we wrap up in the reservations controller, now that we are actually 21:28.380 --> 21:34.770 authenticating our Create Reservation route here, I want to extract the current user on the request 21:34.770 --> 21:39.990 object, which if you remember, we actually set here in the JWT auth guard. 21:39.990 --> 21:44.310 So if you remember, we've already actually implemented this functionality in the auth service. 21:44.310 --> 21:51.390 The current user decorator here where we pull the current user off of the execution context and return 21:51.390 --> 21:53.610 it back to the params decorator. 21:53.640 --> 21:58.830 I'm going to go ahead and export this decorator in our common folder so we can use it in all of our 21:58.830 --> 21:59.820 services. 21:59.820 --> 22:06.360 So let's go ahead and create a new Decorators folder here in our common directory. 22:06.390 --> 22:12.540 I'll follow our similar pattern of creating Index.ts and in our route index, make sure we go ahead 22:12.540 --> 22:15.630 and export everything from decorators. 22:15.630 --> 22:22.080 Now we'll go ahead and copy the current user decorator from the auth project and throw it in the decorators 22:22.080 --> 22:28.650 folder here and we will just make sure we export everything from the current user decorator now. 22:28.650 --> 22:33.480 So make sure you go back to the auth controller and make sure that we are importing the current user 22:33.480 --> 22:36.420 from app slash common here and now. 22:36.420 --> 22:43.260 I'll also go into the reservations controller where we can also use this current user decorator from 22:43.260 --> 22:46.290 app slash common to get the user. 22:46.290 --> 22:52.080 So we want to be able to define a type for this user and, and in particular this user as defined as 22:52.080 --> 22:58.200 a DTO or when it's returned from a network call like in this case from our JWT auth guard. 22:58.200 --> 23:06.060 So let's go into our Libs common folder and we'll create a new directory in the source directory here 23:06.090 --> 23:19.170 called DTO and we will create a new user dot dto ts, which will be an interface that represents a user 23:19.170 --> 23:20.490 data transfer object. 23:20.490 --> 23:27.390 So looking at the user dot schema here, we know that we have an email password and underscore ID. 23:27.690 --> 23:35.280 However, as a DTO, a data transfer object, we know that the object ID will of course be a string 23:35.280 --> 23:38.400 and not an object ID when it's sent over the wire. 23:38.400 --> 23:41.130 So let's go ahead and add these properties. 23:41.130 --> 23:48.600 We have the underscore ID email here as a type string and a password of type string. 23:48.600 --> 23:55.230 So now that we have this, we'll add an index dot ts to our DTO folder will export everything from the 23:55.230 --> 24:02.310 user DTO and our route Index.ts will export everything from the DTO folder. 24:02.340 --> 24:09.870 Additionally, we can go into our Jdbc auth guard and give a type as to user DTO for the send call here, 24:09.870 --> 24:16.080 which will give us some better type inference and actually specify the response here as the user DTO 24:16.110 --> 24:22.590 when we set it on the request object, additionally we can go into the reservations controller now and 24:22.590 --> 24:24.840 actually define this as a user. 24:24.840 --> 24:30.600 DTO And now what I want to do is I want to go into the create call in our reservation service and instead 24:30.600 --> 24:37.530 of hard coding this user ID here, we're going to accept it as an additional user ID parameter which 24:37.530 --> 24:40.740 will come off of the JWT from our off guard. 24:40.740 --> 24:48.720 So now that we're passing the user ID here, we'll go in and pass the user.id as here as well. 24:48.720 --> 24:56.520 And we'll go ahead and set this equal to underscore user and await it just so we can log out the current 24:56.520 --> 24:59.190 user and actually see it, then return it back to the. 24:59.540 --> 25:03.680 We can also see that we're missing an async call in all of these routes. 25:03.680 --> 25:10.490 So let's go ahead and add that and fix this to make sure that we are marking these routes as asynchronous 25:10.490 --> 25:11.150 here. 25:12.230 --> 25:18.500 So back in Postman here, I've updated the body to our reservations call here to include the payload 25:18.500 --> 25:22.880 expected which is the start date, end date, place ID and invoice ID. 25:23.780 --> 25:25.470 So I'll go ahead and send this off. 25:25.490 --> 25:32.600 You can see we have a 201 created and we can see in the logs now we can actually see the user that is 25:32.600 --> 25:37.280 logged out in this route handler, which of course we know is this log here. 25:37.280 --> 25:43.340 So we're correctly extracting the current user after we set it here in the JWT auth guard, which is 25:43.340 --> 25:50.720 excellent because now we have the ability to apply authentication to any route in our microservice architecture. 25:50.870 --> 25:57.560 I'll go ahead and clean this up here by making sure we return just the straight create call here and 25:57.560 --> 26:04.470 then I'm going to go ahead and apply the same JWT auth guard to the remaining of our routes to make 26:04.470 --> 26:08.970 sure that they're all protected by a JWT auth guard. 26:09.000 --> 26:14.760 Now we can call get on our reservations route here and see our two reservations right now.