So, we got our event related routes and we're making sure that only authenticated, so logged
in users can create, edit or delete events.
Now of course, I also want to make sure that we can register for events, but before we
do that, I want to add an extra check to the update and delete routes here.
Because I want to make sure that only the user who created an event is able to actually
edit or delete it.
And there are different ways of achieving this.
We could of course, again, simply ask in chat for help if you were not sure how to do that.
I already know that I essentially want to go to my controller functions here in the
events controller.js file and I want to add the appropriate check there.
So here, after checking whether the received input data is valid, I want to check whether
the currently logged in user is the same user who created an event.
So of course, I don't want to do that here in the create function, but in the edit and
delete functions.
There I get the idea of the event I want to delete and I then want to extract the information
to which user that event belongs.
And then I want to check whether it's the same user as the user who created the event.
Now what's important here though, is that we take a look at the database.js file.
And if we do so, we can see that in this app here, which I built thus far, I'm actually
not storing the information which user created an event in the events table.
Now you might recall that when I planned this application, chat.gpt actually told me to
store that information.
It suggested that I store the creator ID in my event, but I haven't implemented that here
yet.
So I'll do so now.
I'll add a user ID field here, which should be an integer, because the ID of my user is
an integer.
And then I'll also add a foreign key reference like this.
And GitHub Copilot thankfully suggested this to me, that we refer to the ID in the users
table here with that user ID field.
Therefore, of course, we must make sure that we do store such a user ID when a new event
is created.
So we should go to the event.js file in the models folder.
And when we create a new event, we need to store the user ID.
So I'll simply select this and say store user ID in user ID field to update this code appropriately.
We could do it manually, but since I need to change a couple of places, I'd rather use
AI for that.
I now extract a user ID property from the incoming object, and then I store that user
ID here with those code adjustments.
So I'll accept this.
Now I just need to make sure that this user ID is passed to the create event function
from inside the events controller.
So there in the create function, when we call create event, we must make sure that
the user ID is passed to this create event function in that object.
So thankfully, again, GitHub Copilot is making the appropriate suggestion, assuming that
we can extract the user from the request object and then the ID from that user.
And that should be possible because we have the code that adds this user object to the
request object.
We have that code in the auth.js file.
There, the decoded user, so the data we're extracting from the token, is stored under
rec.user.
So we should be able to extract that and then pass it to create event.
So that should make sure that the user ID is stored along with the event.
That then should also allow us to add an extra check that ensures that only the user who
created an event can add it or delete it.
So to check whether the user who tries to add it or delete an event is the user who
created it, we need to add an appropriate check to the edit and the delete item functions
.
here in the events controller.js file. And as always, one way is to simply highlight the entire
function and then ask GitHub Copilot to do it. Check that userId in rec.user is the same as the
ID or as the userId stored for the event that's about to be edited. Let's see whether that works.
Generating some code, some changes. And as it seems, it doesn't change anything here at the
beginning of the function, but then it extracts the event with the getEventById function,
checks if maybe no event was found, in which case a 404 error is returned. But if an event was found,
the userId stored for that event is compared to the userId in the request that if it's not equal,
we also send back an error message. Otherwise, the event is updated accordingly.
So that looks good to me and I'll accept that change. And with that, we should have the
appropriate protection in place. Now, getEventById is a function that is imported from the models
folder from the event.js file, so that should be available. We can now add a similar check
here in delete item and say also check userId. Let's see if that's enough, if there is still
enough context stored by GitHub Copilot. It looks like it is. It gets the event here as well,
gives us a 404 error if it's not found, and otherwise checks the userId. So that is also
looking pretty good. Now, maybe here I want to return a different error message. If we don't
succeed in deleting the event, I actually want to return a 500 error and say event not deleted,
because it technically wasn't not found, it failed to be deleted, which is a different error.
So I guess that makes sense.