[SSF-117]: Backend endpoints user gated

[dburkhart07]

ℹ️ Issue

Closes #117

📝 Description

For this PR, we added in user-specific gated authentication to a few endpoints. The initial problem that required this user gate was that we need to restrict certain endpoints that incorporate the id parameter to specific users (for example, a pantry with the id of 3 should not really be able to do anything involving pantries with ids of 2).

To implement this, we are now marking all endpoints with a guard that allows us to pass in a lambda function. This lambda function uses services within the controller to define how we should go about getting the desired id to compare to the id of the currently signed in user (if they are not the same, access should be denied).

We implement a guard with a decorator, just as we did with the role-based authentication. For the decorator, we created 3 things:

• A resolver to store and run our lambda function to get the proper id we are looking for
• A service registry. This allows us to easily resolve our services so we do not need to worry about circular dependencies. The lambdas resolve only the services that they need, and we use a moduleRef from NestJs to get the appropriate service class so we can actually execute the lambda functions. We store them in a cache so we do not need to keep getting them each time,
• A configuration for ownership checks. This is the top level component that we pass in with our @CheckOwnership decorator. It contains the name of the id for us to use in the parameter, as well as the lambda function that will be resolved.

For the guard, we use each attribute from the decorator to run the following set of logic steps:

• Get the request sent, including the user
• All user admin get to automatically bypass, so check that (this is easy to disable, it is currently 1 line of code)
• Extract the entity id from the request parameters using the configuration's id parameter
• Get the services that we need to resolve the lambda function
• Use the entity and services to resolve the lambda function and get our proper id value
• Compare that id value to the user's id to determine if they should have access

✔️ Verification

For testing, I looked into 2 specific cases. One thing we want to make sure with this PR is that it can handle several services being used in verification (for example with orders, perhaps we are given an order id, and to verify it we need to get the corresponding pantry id, which allows us to get the corresponding pantry which allows us to get the pantry user id which we can check with the signed in user).

For this, I added lambda function guards to an endpoint in the pantries controller (the one called in the request-form page), and one in the orders controller (the one called when we open up the order modal on the admin donation board). I tested both of these pages with and without the corresponding user id being my signed in user. For both of these, I was able to verify that I was kicked out when I wasn't authorized, and allowed in otherwise.

Both these tests ultimately ended up using the pantry_user_id field, but just got to it in different ways.

🏕️ (Optional) Future Work / Notes

This PR is primarily for infrastructure, and we will later need to adjust all of the endpoints accordingly when we decide who we want to give this endpoint access to.

[maxn990]

looks really good over all! i left a few comments, but love the general approach :he-is-brighter:

[maxn990]

i don't think we need to have authenticator wrapped around every route, here's the react documentation on how to do this with significantly less repeat code: https://reactrouter.com/start/declarative/routing

[dburkhart07]

Gonna wait to address this comment for when #94 is merged in

[dburkhart07]

@maxn990 do you think we should abstract the ProtectedRoute too now that #94 is merged in?

[maxn990]

a few nits but looking excellent

[maxn990]

lgtm 🥳

[sam-schu]

Cool design!!

[sam-schu]

As someone who doesn't know too much about Nest modules, I'd like to know more about how this works/why we need it, especially after I saw that the modules we added this to are not the same ones whose controller methods we added the new decorator to

also, would it make more sense to have this be in a sharedAuth directory, since every other module is essentially the top-level file for the directory it is in?

[dburkhart07]

When developing this, I thought we would need a separate module to allow the actual functions from the ownership guard to be used. After doing some testing though, this is not really the case. To me, modules essentially exist to allow us to use the service functions, and access the database entities from the ones we import/include. In this case, where we are rather creating a guard to be applied through a decorator, I dont really think we need it. As long as the guard is passed in as a class to UseGuards, this is all we really need. Ive deleted it since. If you want to investigate more or talk more about it, lmk.