WEBVTT 00:00.830 --> 00:06.170 Next up we are going to cover authentication professionally explained. 00:06.230 --> 00:16.370 Authentication is verifying if you are who you say you are in everyday terms or everyday features that 00:16.370 --> 00:21.710 probably every single one of us has used at least once. 00:21.860 --> 00:30.770 This is the possibilities to have a user account to sign in to that account by using email password 00:30.770 --> 00:32.120 combination. 00:32.270 --> 00:41.540 By having a Remember Me feature that lets you stay signed in for longer periods of time, typically 00:41.540 --> 00:49.070 in weeks, and then being able to create an account by submitting a form. 00:49.850 --> 00:53.360 Now how are we going to achieve that? 00:54.260 --> 01:00.800 We will have to create different modules and different parts of the system. 01:01.760 --> 01:11.570 So I've listed four main building blocks of the authentication system that we are going to create. 01:12.380 --> 01:19.220 So let me start from the second one because controllers is something we already understand. 01:20.120 --> 01:26.300 So we're going to create an authentication controller which would have a couple of functionalities. 01:26.300 --> 01:29.030 One would display a login form. 01:29.030 --> 01:36.650 Another action will handle the form submission where someone would send the username and password. 01:36.650 --> 01:40.550 And also we need an action to log out. 01:40.610 --> 01:46.280 Then we need a view that will display the HTML form. 01:47.750 --> 01:55.340 And inside our user model we need to add functionality to find the user by email. 01:58.550 --> 02:03.710 Then we've got a new type of classes called services. 02:03.710 --> 02:05.930 So what is a service? 02:06.380 --> 02:15.260 Well, there is no specific description of what a service class is, but if I would be to explain that, 02:15.260 --> 02:25.670 I would say that this is the most generic name or namespace for a class that contains some bespoke business 02:25.670 --> 02:26.840 logic. 02:26.870 --> 02:35.450 So in our current scenario, this might be getting the currently authenticated user model. 02:36.050 --> 02:44.270 So this means service classes are classes that can touch different fields. 02:44.420 --> 02:53.090 So getting currently authenticated user model might mean that there needs to be a method that will both 02:53.120 --> 02:59.270 use the sessions, then would be able to fetch something from the database. 02:59.270 --> 03:08.540 So generally it means having a logic that might just use different parts of our system, of our existing 03:08.540 --> 03:09.650 system. 03:10.430 --> 03:17.780 So the features that we're going to put in this class is, as I've said, getting the current user model, 03:17.810 --> 03:26.750 then trying to authenticate the user by verifying the username and password, and then also storing 03:26.750 --> 03:31.430 the user ID in the session and logging out. 03:31.430 --> 03:43.850 Because every single one of those four features contains a couple of steps, and it interacts with different 03:43.850 --> 03:50.480 domains of our app like sessions, cookies, databases, etc.. 03:52.160 --> 04:01.160 And here is the typical flow of how the authentication looks like from the very first screen, where 04:01.160 --> 04:04.880 you see the login form until you log out. 04:04.880 --> 04:08.510 So I would try to explain this simply. 04:09.620 --> 04:18.830 So we always need to start with some way of letting the users verify that they are who they say they 04:18.830 --> 04:22.250 are, and we do that using a login form. 04:22.250 --> 04:28.700 We present the user with two fields the username and password. 04:28.700 --> 04:37.760 Username is often the email, and when this form is submitted, we need to verify user credentials. 04:38.360 --> 04:39.710 How do we do that? 04:40.310 --> 04:46.700 First, we are trying to fetch a user by the specified email or the username. 04:47.510 --> 04:53.210 So we can compare this process to bank employed at some kind of company. 04:53.900 --> 04:58.530 First, to be able to enter you need to be an employee. 04:58.530 --> 05:02.370 So that's the first process checking if you are even employed. 05:02.370 --> 05:08.850 But then you would have to present a valid badge that can be scanned by security. 05:08.850 --> 05:13.350 So they let you in because you can always claim that you are an employee. 05:13.350 --> 05:21.750 But maybe unfortunately you were fired and you no longer have the badge, which is the password, and 05:21.750 --> 05:23.670 you shouldn't be let in. 05:23.670 --> 05:25.680 Same with authentication. 05:25.680 --> 05:30.810 So the next step would be to compare the password hash. 05:30.810 --> 05:32.220 What does that mean. 05:32.220 --> 05:40.020 So it stems from the fact that you don't store passwords in plain text inside the database. 05:40.020 --> 05:41.730 At least you should never do that. 05:41.730 --> 05:47.730 In plain words, this means that let's say my password is just password one two, three. 05:47.940 --> 05:53.190 I would not store this as this string inside the database column. 05:53.190 --> 06:02.190 Instead, I would first make this password go through a process called hashing, which converts the 06:02.190 --> 06:11.790 plaintext password into a hash, which is just a collection of randomly generated strings and the hashing 06:11.790 --> 06:14.550 algorithms for the same input. 06:14.580 --> 06:23.790 They always provide the same output, but if you see a hash, there is very little chance that you would 06:23.820 --> 06:25.920 be able to figure out the password. 06:25.920 --> 06:31.590 Now, the way this process works is that you store a hashed password. 06:31.590 --> 06:39.000 Thus you also give some extra security to your users because if someone breaks in to the database, 06:39.000 --> 06:40.950 he won't know all the passwords. 06:40.950 --> 06:48.960 And additionally, you don't know the passwords of your users, which might give them more safety and 06:48.960 --> 06:51.360 they might trust you more. 06:51.390 --> 06:59.050 I say we compare the password hash because what we do is we compare what the user has entered, we generate 06:59.080 --> 07:07.780 a hash of it, and then we compare that with a hash that we have stored inside the database. 07:07.810 --> 07:13.030 This sounds complicated, but in PHP this is just a single function call. 07:13.060 --> 07:21.430 Because PHP comes with a function that can verify hashed passwords, and also with another one that 07:21.430 --> 07:23.080 can hash a text. 07:23.800 --> 07:32.560 So if the hash that was generated from the user input matches with the hash stored inside the database 07:32.560 --> 07:41.710 in the user's table password column, the next step is to store this user ID inside the current session. 07:42.190 --> 07:49.240 And then whenever we need to retrieve the currently authenticated user, we just look up the session. 07:49.240 --> 07:56.340 If there is the user ID and we fetch the user by ID from the database. 07:56.340 --> 08:05.430 This is how the user can stay authenticated because we store his user ID in his session that will anyway 08:05.460 --> 08:08.970 automatically expire after some time. 08:08.970 --> 08:18.660 So this gives us extra safety that the user would be logged out after certain time of inactivity, but 08:18.660 --> 08:26.520 additionally, he should have an option to log out explicitly manually, and this would involve clearing 08:26.520 --> 08:31.110 the user ID from the session or even regenerating the session. 08:31.110 --> 08:35.850 So this is more or less how the authentication process looks like. 08:36.030 --> 08:44.250 Now there is obviously more to it, and we are going to talk about the details once we work with the 08:44.250 --> 08:46.620 specific parts of this process. 08:47.490 --> 08:54.540 For now, let's just begin building this authentication system for the current project.