[WIP] Backend authentication RBAC refactor #497
Conversation
Started off by refactoring the getPageData request. Also refactoring the file structure for easier maintainence/contribution
… into v2/backend/rbac
|
Update: completed moving over gameplay routes to new file structure. |
|
It appears atm this PR is ready for review. File structure migrations has been completed and some major security issues were addressed in regards to database queries and not requiring enough / minimal fields to determine which records to retrieve. In some instances, if you spoofed a userId, you could gain access to apikeys or other models that were not yours... |
| const query = await prisma.v2Account.findFirst({ | ||
| where: { | ||
| providerAccountId: | ||
| logto_user.userInfo.identities[ |
There was a problem hiding this comment.
Can we assign this to a variable like providerAccountId just to clean things up a bit
| if (!query || query == null) | ||
| await prisma.v2Account.create({ | ||
| data: { | ||
| provider: Object.keys(logto_user.userInfo.identities)[0], |
There was a problem hiding this comment.
Run Object.keys once and assign to a variable and grab the ID needed above from this variable
| // always update user data on sign-in | ||
| try { | ||
| const result = await prisma.account.findFirst({ | ||
| const result = await prisma.v2Account.findFirst({ | ||
| where: { | ||
| providerAccountId: | ||
| logto_user.userInfo.identities[ | ||
| Object.keys(logto_user.userInfo.identities)[0] |
There was a problem hiding this comment.
Same as above here please.
| 'read:gameplay', | ||
| ]) | ||
| .meta({ openapi: { method: 'GET', path: '/clip' } }) | ||
| .input( |
There was a problem hiding this comment.
Can the zod input/output schemas be assigned to their own variable please. See gameplay/create.ts
There was a problem hiding this comment.
I don't think we need to do this if the object is that small.. I think it would be viable if the object had maybe 2-3 more values but just one doesn't make sense unless this input policy would be used in more than 1 route.
There was a problem hiding this comment.
It would make sense to me to match the rest of the codebase, it's more of a readability/convention issue.
…e to explain better
Description
This will eventually refactor all the current backend code into use logto's RBAC system to authenticate use of the backend API depending the permissions the logged in user has.
This will also refactor the current backend file structure for improved readability, contribution and maintenance.
Routers to refactor
Issues