More granular permissions (attribute/field level permissions)

[jappyjan]

🚀 Feature

Currently i can only deny access to a whole document/collection but not restrict acces of certain fields (like createdAt or similiar non mutatable fields)
Also there is no way of adding generated fields like a uuid or the current date/timestamp.

This is quite basic stuff i guess... weird that i could not find any other issue/request here...

[eldadfux]

Can you share more about your use-case? Usually what I do in this situation is to leverage multiple collections or multiple documents and sync data using cloud functions. That way I can still get lots of flexibility using a relative simple permissions model.

[jappyjan]

I guess my use case is to avoid exactly what you described as a solution 😅 I mean you’re totally right that this is an option, but it kinda defeats (slightly) the BaaS concept if I have to kinda implement security/permission systems on my own instead of only configuring them

…

Am 26.06.2021 um 17:58 schrieb Eldad A. Fux ***@***.***>:  Can you share more about your use-case? Usually what I do in this situation is to leverage multiple collections or multiple documents and sync data using cloud functions. That way I can still get lots of flexibility using a relative simple permissions model. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[eldadfux]

I totally understand where you coming from, but at the end of the day this is all a compromise between flexibility, ease of usage and performance. Checking for permission access for each attribute can be a killer for performance.

In big scale application the go to solution would probably be multiple collections with sync functionality or managing all write from a single cloud function who is the only one with write access to the collections.

[rdmchr]

I think it's a good idea to offer users the option to define more granular permissions like Firebase, where you can check if specific fields have specific values.

You're probably right with the performance concerns, but at the end of the day, a user should be able to decide for themselves if they want to take that performance loss or not.

[Meldiron]

Come to think of it, this opens security issues on every project with multiple users, right?

**Example:**I have a simple chatting platform.. I can create a message with someone else ID and make it look like someone else send the message.

Maybe we should not focus on supporting per-parameter permissions, instead, let's just add one security layer that will tell appwrite to append user's ID into a document. This way we don't need to trust the client, the "userId" would be added by Appwrite PHP.

---

Anyone can see a problem with this approach? Any other cases that would not be solved by this?

[rdmchr]

Good idea, but I would like to extend that idea:
Some fields can be locked, meaning that once they have a value users can't change that, even if they have the write permission (this may or may not be overridable by a server SDK; I currently can't find a reason why not).
This would allow me to create a document for another user, but that user can't just change the userid.
I think some kind of lock would also be interesting for other use cases.

[gireeshp]

In Firebase, they have implemented field level permission in such a way that they can be validated looking at the query itself (not looking at the data stored in the DB) when it comes to reading a bunch of records. Of course they look at both query and the data in DB when it comes to single record read/write/update. This is done to avoid potential performance issues.

I guess field level permissions are critical to handle scenarios such as:

• Letting only the author of the review to edit it, while all others can see it OR
• Letting only the author see the draft reviews (status = 'draft') whereas everyone else can see the published reviews.

Implementing such checks using a separate collection would be a little too much overhead I guess.

[stnguyen90]

Let's focus this issue on the granular permissions rather than "powerful defaults"

[Ja0073]

I've been following the development of the upcoming version and its new permissions features. While I understand this might be outside the current scope maybe, I wanted to suggest a feature that I believe would significantly enhance the flexibility of the permissions system.
Specifically, I propose the ability to add individual user IDs to a blacklist. This would complement the existing whitelist feature, allowing for more granular control over user access.
A common use case for this would be in social features like user search or profiles. When a user blocks another user, it would be beneficial to restrict their access to certain parts of that user's profile or even prevent them from appearing in search results. Currently, achieving this requires granting read permissions to all users except the blocked one, which is quite cumbersome. A blacklist feature would streamline this process.