-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is there a work around to separate addField constraint for pointer permission #4251
Comments
You can update the schema directly using the REST API. This is likely to be a limitation on the dashboard. Can you ping back if there’s an issue? |
i don't understand how to change the schema directly, when i get '/schemas/Test' for some test class i created i get something like this for the CLP:
the user pointer has the hole write privilege specified with 'writeUserFields' and when i try 'addFieldUserFields' instead of 'writeUserFields' it gives an error. |
It should probably be in |
when put :
it gives:
|
Ok thanks! |
+1 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@flovilmart I don't think it is a limitation for the dashboard. When I look at the database I see this It seems to be saved separately. So the workaround would be have some cloud function code save specific user permission for each object beforeSave. I'm not sure yet, I'll be trying it. |
It need to be implemented on the server as for now, pointer Permissions are blanket par missions for read or write, and don’t offer granular control over each detailed permission. |
@bouzoumita The workaround I imagined does not work exactly for some reason. When I have object level permission like this set by code:
So sadly, if your registered user decides to attack you, they can add many many fields to their own object and cause who knows what issue. @flovilmart any thoughts? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
may be you want take look at #4045.
because 4045 is inactive for a long time i opened a new one. it is critical, while a user in this case has privilege more then the admin it self, is there a work around this.
The text was updated successfully, but these errors were encountered: