WEBVTT 00:02.480 --> 00:07.610 So let's get started with the process of logging a user out once they're deleted, so the first thing 00:07.610 --> 00:13.190 I want to draw here attention is this handler delete user in handler's dash API Dutko. 00:14.070 --> 00:19.500 All this really does is delete the user from the user's table in this function right here and delete 00:19.500 --> 00:23.010 user and that it sends back and OK, if it succeeded in doing so. 00:24.000 --> 00:29.580 But if you look at the database and we look at the tokens table right here. 00:30.480 --> 00:36.780 You'll see that we still have a token for user I.D., too, who has been deleted, and that's because 00:36.780 --> 00:42.020 there's no foreign key relationship between user ID in this table and ID and the users table. 00:43.320 --> 00:49.590 So we could if we wanted to set up a foreign key relationship and that would automatically delete this. 00:49.590 --> 00:50.550 And that's easy enough. 00:50.550 --> 00:53.880 Or we can go modify the code that actually takes care of that. 00:53.940 --> 00:59.370 Now, the good thing, of course, is that because when we look up at token, we're using user ID. 01:00.450 --> 01:04.830 This road never gets found because that user ID doesn't exist in the user's table anymore. 01:05.040 --> 01:07.930 But we still should clean up this token since we don't need it anymore. 01:07.950 --> 01:12.270 So let's go back and just take care of that and we'll do it at the code level, not at the database 01:12.270 --> 01:12.630 level. 01:13.080 --> 01:16.980 So we'll go over to delete user at this function, which is in model go. 01:17.100 --> 01:23.040 And all I have to do here is before I return nil, let's just clean this up a little bit. 01:24.480 --> 01:25.620 I just create another statement. 01:25.620 --> 01:36.890 That statement equals delete from tokens where user of equals questionmark and then I execute that. 01:37.230 --> 01:39.350 So don't care about the first result. 01:39.360 --> 01:51.300 Do care about the error equals m db the exact context and at the context and in our statement and handed 01:51.300 --> 01:53.180 IP and we check for an error. 01:53.190 --> 01:54.570 So we'll just copy this code. 01:56.280 --> 02:01.680 And of course, this can't be the assignment operator, since we already have an air base that in there 02:02.670 --> 02:08.370 and the next time we run this, it will automatically delete the user and then it will delete any token 02:08.370 --> 02:09.490 associated with the user. 02:09.510 --> 02:10.520 So that's a good start. 02:11.700 --> 02:14.050 But of course, that doesn't actually log the user out. 02:14.130 --> 02:15.210 That's just a bit of cleanup. 02:15.510 --> 02:21.720 So back here and handlers thought API, when this is called, how do we make sure that the user is logged 02:21.720 --> 02:21.960 out? 02:22.320 --> 02:23.670 Well, we could do it in the middleware. 02:23.880 --> 02:28.080 So if we open up our middleware, which is right here under. 02:29.540 --> 02:34.550 Command web, we have this one off we could if we wanted to. 02:35.290 --> 02:40.880 I actually do a database look up right at this point, we have access to the necessary functions because 02:40.880 --> 02:47.180 we have the receiver app of type pointer to application so we could at this point check for the existence 02:47.180 --> 02:52.940 of user I.D., then read that value into it, and then check the user's table to see if that user still 02:52.940 --> 02:54.730 exists and where we go. 02:54.740 --> 02:56.120 And that would absolutely do the trick. 02:56.840 --> 03:00.920 Of course, it doesn't instantly log the user out. 03:01.100 --> 03:06.320 And ideally, what I would like to do is log that user out as soon as that user is deleted. 03:07.160 --> 03:13.520 And of course, the other problem here is that every single time and authenticated user tries to access 03:13.520 --> 03:18.680 something, we're doing a database lookup and those are relatively expensive in terms of system resources. 03:19.460 --> 03:24.740 So I think we're going to take an alternate approach at this point and we'll do something using WebSocket 03:24.860 --> 03:27.070 and we'll start that in the next election.