Conversation
dburkhart07
changed the title
maxn990
left a comment
maxn990
left a comment
There was a problem hiding this comment.
looks really good over all! i left a few comments, but love the general approach :he-is-brighter:
|
|
||
| Finally, run `yarn run typeorm:migrate` to load all the tables into your database. If everything is set up correctly, you should see "Migration ... has been executed successfully." in the terminal. | ||
|
|
||
| # AWS Setup |
| path: '/landing-page', | ||
| element: ( | ||
| <Authenticator components={components}> | ||
| <LandingPage /> | ||
| </Authenticator> | ||
| ), | ||
| }, | ||
| { | ||
| path: '/pantry-overview', | ||
| element: ( | ||
| <Authenticator components={components}> | ||
| <PantryOverview /> | ||
| </Authenticator> | ||
| ), | ||
| }, | ||
| { | ||
| path: '/pantry-dashboard/:pantryId', | ||
| element: ( | ||
| <Authenticator components={components}> |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Gonna wait to address this comment for when #94 is merged in
maxn990
left a comment
maxn990
left a comment
There was a problem hiding this comment.
a few nits but looking excellent
|
|
||
| @Controller('donation-items') | ||
| //@UseInterceptors() | ||
| @UseGuards(AuthGuard('jwt')) |
There was a problem hiding this comment.
i could be wrong because this is more of a product question, but should a user only be able to access donation items they donate? in other words why auth guard here over ownership guard
There was a problem hiding this comment.
The whole idea behind this ticket was that it would be an architecture feature that we could easily integrate into any endpoint we wanted when we have a better idea of how we want to restrict thnigs. Putting sepcific restrictions right now could also make testing a real pain, so I personally am not eager to implement all of these gates until a majority of feature development is finished.
| if (error.response?.status === 403 && this.navigate) { | ||
| const errorData = error.response?.data as { message?: string }; | ||
| this.navigate('/unauthorized', { | ||
| replace: true, | ||
| state: { | ||
| errorMessage: errorData?.message || 'Access forbidden', | ||
| }, | ||
| }); |
3 participants
ℹ️ 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:
moduleReffrom 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,@CheckOwnershipdecorator. 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:
✔️ 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_idfield, 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.