You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I can't seem to get Payload to work on DigitalOcean App Platform as expected - it seems as though the user in the request object isn't getting passed to the access functions for update and I can't figure out why as my same access control logic is working for the read access function.
From console logging it seems that req.user is undefined for some reason on update but not on read - I've tried removing my access control logic entirely from one of the collections and that has no effect. I was thinking that it could've been cookies with csrf, but I'm pretty sure that is all set - and if I go to the requested API URL it seems to work.
Here's what I'm working with: Turborepo, Sentry's NodeJS SDK added to the express app, port set via environment variables using DigitalOcean's ${_self.PRIVATE_PORT}, MongoDB on Atlas, S3-compatible storage also with DigitalOcean. It builds on DigitalOcean alright, just got the mentioned issues with access control. I'm using payload v1.8.2 but previously v1.6.19 but I've read through the changelog and didn't see anything that I thought would affect my use case.
Anyone got any ideas? Theres definitely a chance that I've configured something weird in my DigitalOcean App Spec but its been a lot of head scratching.
# DigitalOcean App Specalerts:
- rule: DEPLOYMENT_FAILED
- rule: DOMAIN_FAILEDenvs:
# Some Environment config set here :)name: exampleapp-cmsregion: lonservices:
- build_command: yarn run build --filter=cms --no-cacheenvironment_slug: node-jsgithub:
branch: mainrepo: # Omitteddeploy_on_push: falseinstance_count: 1instance_size_slug: basic-xxshttp_port: 443name: exampleapp-apps-cmsroutes:
- path: /run_command: yarn run serve --filter=cms --no-cache
Thank you in advance, I've tried so many random things to try and fix this - my next step would be to start from scratch and gradually add the collections back in...
The access control logic
import{FieldAccess}from"payload/types";import{User}from"payload/generated-types";import{Access}from"payload/types";constroles={public: 0,subscriber: 10,admin: 20,superAdmin: 30,};exportdefaultfunctionroleOf(user?: User): keyoftypeofroles|null{// Check whether there is a userif(!user){return"public";}// Check whether the user has an assigned roleif(!("role"inuser)||!user.role){// Default to publicreturn"public";}// Check whether the assigned role is an accepted value (for edge cases and changes)if(!Object.keys(roles).includes(user.role)){// Fallback to publicreturn"public";}returnuser.role;}exportdefaultfunctionhasCollectionAccessRole(requiredRole: keyoftypeofroles): Access<any,User>{// eslint-disable-linereturn({req: { user }})=>{// Deny all if required role doesn't exist or have a given priorityif(!(requiredRoleinroles)||typeofroles[requiredRole]!=="number"){returnfalse;}// Determine the required role's priorityconstrequiredRolePriority=roles[requiredRole];// Determine the role of the current userconstuserRole=roleOf(user);console.log("Found user role:",userRole);// Deny if the user's role doesn't exist (we shouldn't get here using roleOf)if(!(userRoleinroles)||typeofroles[userRole]!=="number"){returnfalse;}constuserRolePriority=roles[userRole];// Determine access based on priority-based precedenceif(userRolePriority>=requiredRolePriority){returntrue;}// Deny as a fallback and defaultreturnfalse;};}exportdefaultfunctionhasFieldAccessRole(requiredRole: keyoftypeofroles): FieldAccess<{id: string},unknown,User>{return({req: { user }})=>{// Deny all if required role doesn't exist or have a given priorityif(!(requiredRoleinroles)||typeofroles[requiredRole]!=="number"){returnfalse;}// Determine the required role's priorityconstrequiredRolePriority=roles[requiredRole];// Determine the role of the current userconstuserRole=roleOf(user);// Deny if the user's role doesn't exist (we shouldn't get here using roleOf)if(!(userRoleinroles)||typeofroles[userRole]!=="number"){returnfalse;}constuserRolePriority=roles[userRole];// Determine access based on priority-based precedenceif(userRolePriority>=requiredRolePriority){returntrue;}// Deny as a fallback and defaultreturnfalse;};}
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi, I can't seem to get Payload to work on DigitalOcean App Platform as expected - it seems as though the user in the request object isn't getting passed to the access functions for update and I can't figure out why as my same access control logic is working for the read access function.
From console logging it seems that
req.user
is undefined for some reason on update but not on read - I've tried removing my access control logic entirely from one of the collections and that has no effect. I was thinking that it could've been cookies with csrf, but I'm pretty sure that is all set - and if I go to the requested API URL it seems to work.Here's what I'm working with: Turborepo, Sentry's NodeJS SDK added to the express app, port set via environment variables using DigitalOcean's
${_self.PRIVATE_PORT}
, MongoDB on Atlas, S3-compatible storage also with DigitalOcean. It builds on DigitalOcean alright, just got the mentioned issues with access control. I'm using payload v1.8.2 but previously v1.6.19 but I've read through the changelog and didn't see anything that I thought would affect my use case.Anyone got any ideas? Theres definitely a chance that I've configured something weird in my DigitalOcean App Spec but its been a lot of head scratching.
Thank you in advance, I've tried so many random things to try and fix this - my next step would be to start from scratch and gradually add the collections back in...
The access control logic
Beta Was this translation helpful? Give feedback.
All reactions