So now if we make it past all these
if checks in the signup action,
we know that we have valid input data and that we
therefore wanna store a new user in the database.
Therefore, as a first step, I want to add a new file
to that lib folder.
And I'll name it user dot js.
The name is up to you, of course, as always.
And in there, I want
to export a function called create user,
which should do what the name suggests.
It should take an email and a password,
and it should then store that combination in the database.
For that, we need our database handle.
So we need to import DB from the DB file.
And then there we can prepare a statement, a SQL statement,
where I want to insert a new value into the users table.
And I wanna set the email and password fields.
And the values will be two placeholders here,
which will be replaced soon
because I'll then call a run on that prepared statement.
And now there we pass the concrete values
for those question mark placeholders,
so the email and the password.
And that will give us a result.
So we'll get a result of running this database query
and I then wanna return that result,
or specifically there the last insert row ID,
so the ID for that user that was now newly created.
Now this SQL statement here
should be pretty self-explanatory.
And this DB thing, which I'm using here is in the end,
an object that's provided
by that better SQLite 3 package,
which gives us methods like the prepare
and run method here that allow us to interact
with our SQLite database.
So that would create a new user and
therefore in our auth actions JS file,
after validating the input, we could run create user.
So import this function
from that user JS file I just created in the lib folder,
and then pass our validated email
and password to this function to create that user.
That's how we could do it,
but this approach would have a very big flaw
and security problem.
And do you have an idea what the problem
with this approach here would be?
Well, the problem with creating a user like this
would be that we would take the password that was entered
by the user in the form,
and we would store it just like this
as plain text in the end, in the database,
which means that any employee, if they have access
to that database, could extract the passwords of our users.
We, as the owner, could see the passwords of our users,
and our users probably wouldn't like that.
And if our database ever gets compromised, gets attacked
and hacked, then those attackers
would retrieve emails and passwords stored in plain text
and they could then try those email password combinations
on other sites because people tend to reuse passwords.
And therefore, as a very simple
yet important rule,
you should never store plain text passwords.
So we should not pass the password as it was entered
by the user into our database.
Instead, we should first hash it, so we should convert it
to some strange looking string,
which can't be converted back
so that if that string ever gets compromised,
nobody knows what the original password was.
And that's what we'll work on next.