1 00:00:00,000 --> 00:00:03,000 So now if we make it past all these 2 00:00:03,000 --> 00:00:06,000 if checks in the signup action, 3 00:00:06,000 --> 00:00:10,000 we know that we have valid input data and that we 4 00:00:10,000 --> 00:00:13,000 therefore wanna store a new user in the database. 5 00:00:14,000 --> 00:00:19,000 Therefore, as a first step, I want to add a new file 6 00:00:19,000 --> 00:00:21,000 to that lib folder. 7 00:00:21,000 --> 00:00:23,000 And I'll name it user dot js. 8 00:00:23,000 --> 00:00:26,000 The name is up to you, of course, as always. 9 00:00:27,000 --> 00:00:28,000 And in there, I want 10 00:00:28,000 --> 00:00:31,000 to export a function called create user, 11 00:00:31,000 --> 00:00:34,000 which should do what the name suggests. 12 00:00:34,000 --> 00:00:37,000 It should take an email and a password, 13 00:00:37,000 --> 00:00:41,000 and it should then store that combination in the database. 14 00:00:42,000 --> 00:00:45,000 For that, we need our database handle. 15 00:00:45,000 --> 00:00:48,000 So we need to import DB from the DB file. 16 00:00:48,000 --> 00:00:53,000 And then there we can prepare a statement, a SQL statement, 17 00:00:53,000 --> 00:00:58,000 where I want to insert a new value into the users table. 18 00:00:59,000 --> 00:01:03,000 And I wanna set the email and password fields. 19 00:01:03,000 --> 00:01:08,000 And the values will be two placeholders here, 20 00:01:08,000 --> 00:01:10,000 which will be replaced soon 21 00:01:10,000 --> 00:01:13,000 because I'll then call a run on that prepared statement. 22 00:01:13,000 --> 00:01:15,000 And now there we pass the concrete values 23 00:01:15,000 --> 00:01:18,000 for those question mark placeholders, 24 00:01:18,000 --> 00:01:21,000 so the email and the password. 25 00:01:23,000 --> 00:01:26,000 And that will give us a result. 26 00:01:26,000 --> 00:01:29,000 So we'll get a result of running this database query 27 00:01:29,000 --> 00:01:32,000 and I then wanna return that result, 28 00:01:32,000 --> 00:01:35,000 or specifically there the last insert row ID, 29 00:01:35,000 --> 00:01:40,000 so the ID for that user that was now newly created. 30 00:01:42,000 --> 00:01:44,000 Now this SQL statement here 31 00:01:44,000 --> 00:01:46,000 should be pretty self-explanatory. 32 00:01:46,000 --> 00:01:51,000 And this DB thing, which I'm using here is in the end, 33 00:01:51,000 --> 00:01:53,000 an object that's provided 34 00:01:53,000 --> 00:01:55,000 by that better SQLite 3 package, 35 00:01:55,000 --> 00:01:58,000 which gives us methods like the prepare 36 00:01:58,000 --> 00:02:01,000 and run method here that allow us to interact 37 00:02:01,000 --> 00:02:03,000 with our SQLite database. 38 00:02:04,000 --> 00:02:07,000 So that would create a new user and 39 00:02:07,000 --> 00:02:11,000 therefore in our auth actions JS file, 40 00:02:11,000 --> 00:02:16,000 after validating the input, we could run create user. 41 00:02:16,000 --> 00:02:19,000 So import this function 42 00:02:19,000 --> 00:02:24,000 from that user JS file I just created in the lib folder, 43 00:02:24,000 --> 00:02:28,000 and then pass our validated email 44 00:02:28,000 --> 00:02:32,000 and password to this function to create that user. 45 00:02:32,000 --> 00:02:34,000 That's how we could do it, 46 00:02:34,000 --> 00:02:39,000 but this approach would have a very big flaw 47 00:02:39,000 --> 00:02:42,000 and security problem. 48 00:02:42,000 --> 00:02:45,000 And do you have an idea what the problem 49 00:02:45,000 --> 00:02:48,000 with this approach here would be? 50 00:02:50,000 --> 00:02:54,000 Well, the problem with creating a user like this 51 00:02:54,000 --> 00:02:59,000 would be that we would take the password that was entered 52 00:02:59,000 --> 00:03:00,000 by the user in the form, 53 00:03:00,000 --> 00:03:03,000 and we would store it just like this 54 00:03:03,000 --> 00:03:07,000 as plain text in the end, in the database, 55 00:03:09,000 --> 00:03:13,000 which means that any employee, if they have access 56 00:03:13,000 --> 00:03:17,000 to that database, could extract the passwords of our users. 57 00:03:17,000 --> 00:03:21,000 We, as the owner, could see the passwords of our users, 58 00:03:21,000 --> 00:03:25,000 and our users probably wouldn't like that. 59 00:03:25,000 --> 00:03:30,000 And if our database ever gets compromised, gets attacked 60 00:03:30,000 --> 00:03:33,000 and hacked, then those attackers 61 00:03:33,000 --> 00:03:38,000 would retrieve emails and passwords stored in plain text 62 00:03:38,000 --> 00:03:42,000 and they could then try those email password combinations 63 00:03:42,000 --> 00:03:47,000 on other sites because people tend to reuse passwords. 64 00:03:48,000 --> 00:03:51,000 And therefore, as a very simple 65 00:03:51,000 --> 00:03:53,000 yet important rule, 66 00:03:53,000 --> 00:03:58,000 you should never store plain text passwords. 67 00:04:00,000 --> 00:04:04,000 So we should not pass the password as it was entered 68 00:04:04,000 --> 00:04:07,000 by the user into our database. 69 00:04:07,000 --> 00:04:11,000 Instead, we should first hash it, so we should convert it 70 00:04:11,000 --> 00:04:14,000 to some strange looking string, 71 00:04:14,000 --> 00:04:16,000 which can't be converted back 72 00:04:16,000 --> 00:04:21,000 so that if that string ever gets compromised, 73 00:04:21,000 --> 00:04:25,000 nobody knows what the original password was. 74 00:04:25,000 --> 00:04:28,000 And that's what we'll work on next.