Flexibility when using Permissions (document access using conditional logic)

[wiledal]

Just got home from vacation and was excited to try out Appwrite, so I started building a small Twitter clone. I really enjoyed the ease of setup and vast scope of functionality! Unfortunately there's a heck-ton of great features that I didn't get to try out, as I got immediately put off by the lack of flexibility around Permissions.

It seems that it's more or less impossible to accomplish even basic things safely without introducing a custom backend, and in the end I will need to lock down every single client-facing API, reducing the usability of the web api to read-only operations.

Take for instance a very basic Twitter-clone,

• Every User has exactly one UserProfile
  • This means Users need to be able to create one UserProfile, and only for themselves
• Every user can create Tweets
  • This means Users needs to be able to create many Tweets, but only for themselves

In Firebase

• In order to allow users to create UserProfiles and Tweets, we add Security Rules
• Security Rules can use document matching and conditional expressions based on the authed User's id amongst other things.

✅ The Security Rules can be set up so that users only have write access to a single UserProfile, which must be their own.
✅ The Security Rules can be set up so that they are only allowed to create "Tweets" with their own authed id as Tweet.owner.

Reference: https://firebase.google.com/docs/firestore/security/rules-conditions

In Appwrite

• In order to allow Users to create UserProfiles, we need to allow all Users the CREATE permission.
  • ⚠️ This allows Users to create nth UserProfiles, and could supply any owner id, which allows creating UserProfiles for any User.
• In order to allow Users to create Tweets, we allow all Users the CREATE permission.
  • ⚠️ This allows Users to create Tweets with any owner id, which allows creating Tweets for any User.

In order to mitigate this, we'll need to

• Remove the CREATE, and UPDATE permissions for both Tweets and UserProfiles, and
  • ⚠️ If we don't remove the UPDATE permission, a user can change the Tweet.owner after creation
• Set up an entire bff (backend-for-frontend), or Appwrite Function, with document-fetching boilerplate, conditions, custom error messages, etc etc
• This is common practice when rolling traditional backends, but I did not expect to have to write my own code for this.

Also, setting document-level permissions in the client request is not really convenient imho. Not only is it unsafe and prone to error, it will cause a huge headache when conditions inevitably change ⏲️.

I find the beauty of Firebase (and Pocketbase, and Supabase to some extent), is that they let us utilize Storage and Database access permissions that essentially eliminate the need for any backend code - or a server at all for that matter. At least for simple applications!

Is there further discussion around this topic? Are there any best practices around how to do this "the Appwrite way"?

Thanks!

---

Edit:
I did some further searching and found this, which essentially asks the same question as me:
#3705

The accepted "solution" is suggesting what I wrote above: essentially making your own CRUD endpoints for every resource using Appwrite Functions. I'm not really satisfied with this answer 😞. This will be required by every project that uses the Database service, so it would make sense to have a built-in dynamic validation system that can reject bad attempts.

[wiledal]

I wonder how developers are using the current Permissions in production -- do they have zero care for data integrity? I cannot see how I can get around rolling my own CRUD-functions for each Database and Storage request.

This comes with a number of drawbacks, off the top of my head:

• not using the packaged solution, maintenance is on me
• proprietary, undocumented code with no community support
• slower execution time (I assume, since this runs in a separate function-runtime)
• custom error handling and messaging
• boilerplate, boilerplate, boilerplate
• no graphql support*
• no realtime support*
• cannot control Function methods or status codes, so I am forced to use POST and return errors incorrectly as status 200

Wins:

• granular control over access
• when features change, I can change access logic in a single place (instead of having to run a script to migrate permissions on nth documents)

It should probably be mentioned in the documentation if this is the expected usage, and if it is, maybe provide some tooling for it? I'm starting to structure my own tools for this now, but it does feel off reinventing the wheel and having to ignore entire Appwrite features.

⚠️ The "30 days of Appwrite" promotes these flawed Permissions https://dev.to/appwrite/30daysofappwrite-create-user-profiles-1c3m. That UserProfile has WRITE permissions, so you could extremely easily change its owner id to another user which would hijack their profile, and the affected user would not have permissions to change it 😅

I'm still doubting myself here, maybe I've missed something 😄 - are there better methods for this that I haven't considered?

[Meldiron]

Hey there 👋

Your concerns are valid. We are actively discussing more server variables similar to unique() ID. Other variables could be now(), userId(), and so on. Those are not part of Appwrite yet.

As you mentioned, the best way to have a 100% secure solution as of right now is Appwrite Functions. What I usually do is one generic function that listens to all .create and .update events, so it triggers automatically whenever there is anything new or updated in any collection.

In the code, I look for specific attributes by name, and forcefully replace the value, but only if necessary. That way if the attacker set ID to value of another user, the function would very quickly correct that. This is pretty much the same solution that server variables would be, with the main difference being that it's async, and maintained by you.

Another solution would be to use frontend rendering framework features, such as actions in Svelte Kit, or custom endpoints in Next.js. You can relay that those are executed on the server, and you can do server-side logic there as well. It will not only solve the security, but also bring in other advantages, such as server-side rendering, and possibly make your website work without JS.

---

With that said, I still understand your frustration, and I agree this should be addressed. I shared this discussion with the team internally to get more feedback on the topic.

[wiledal]

Having an event based Function is an interesting approach! But, does the Function see which User triggered the event? In the docs (https://appwrite.io/docs/events) it seems the payload only contains the document object.

Will the APPWRITE_FUNCTION_USER_ID be populated by the responsible user? 🤔

[Meldiron]

populated by the responsible user

Yes, it should be ✨

[wiledal]

It does the job! I like the idea of having this decoupled task. Makes us able to rely on the Permissions rather than re-implementing them. The user won't be notified of the error, but it "should" only happen during malicious intent, so screw those users anyways.

It's not perfect, since there will be a brief state of wrongful data, and if the Function fails we are cooked... If only we could have a filtering / sanitation / transformation layer which triggers before the data is added 🤔

[DeepBhat]

Hey there, I did not fully understand this approach. Specifically, how do you "forcefully replace the value"? Say a malicious user updates some attribute a's value from xyz to abc. When the function triggers and realizes the malicious user was not allowed to change a, how do you know what the previous value was? Do you fetch it from the backup? Or will the event payload itself tell you what the old and new values are?

[gewenyu99]

The payload will have this value. You can, of course, also just wrap update methods with an Appwrite Function, which you can now track and update along with your application code with automated GitHub deployment, so it's more maintainable.

With that said, we'll probably have a more integrated way to implement security rules.

[gewenyu99]

Subscribing to the thread. We're thinking of improving this stuff in the next release (no promises).

Thanks for brining this up!

[wiledal]

Exciting. Is there any public roadmap apart from the issue backlog here on GitHub?
I'm considering using Appwrite for an upcoming project, but without a functional sanitation layer in-between database requests, I'm hesitant.

The fact that you cannot use Appwrite out-of-the-box for any "real" project, makes it less attractive. There's simply no way to reach any data-based business goals without using custom undocumented methods that are hard, if not impossible, to test and troubleshoot locally (those darn functions).

To me, Appwrite at present moment feels like a house with no windows or doors, just empty frames. The house looks great, has great wifi, fully equipped kitchen, and stylish toilets, there's even a jacuzzi on the roof! However, when I ask "how can I put a door on this house?" people tell me to either "use the door we provide, it works great, but it doesn't come with any locks", or, to build one myself out of scrap wood and hammer it to the bricks. If it doesn't work the first time I have to remove the nails, adjust it, then hammer it back on again. The process is tedious and half-baked.

I checked out some showcased projects on https://builtwith.appwrite.io today, to see if they left those door frames open. For the "twitter"-like apps on there, I could impersonate any user and increase "like" counts to infinity. All it took was a click and a keystroke. That's not a true reflection on Appwrite, as the apps seem to be built by students, but it does pose a question about how Appwrite is unsafe by default (something that inexperienced developers might not understand).

The reason why I'm so engaged is because I really want Appwrite to succeed, but I cannot see myself using this when unofficial workarounds is the "preferred method" for some of the most common usecases, like adding a document to the database.

[gewenyu99]

😉 Keep in mind this project is in early stages, we started in 2020, and even now, there are probably 15 engineers working on this. We can't throw hundreds of engineers at a problem and just make it appear out of thin air, as much as we want to.

In terms of roadmaps, no promises, we're not in a stage where we can plan "far ahead", but we'll be there soon. There's sooooo many important features to implement.

Where you could help, is to contribute parts of this feature.

I would first look at our RFC repo, maybe submit an RFC for suggested solutions and work with our engineers to design a solution to this problem:
https://github.com/appwrite/rfc

You can also help with the implementation after we collaborate on the feature design in the RFC.

We want Appwrite to succeed, too, but there's only so many of us 😅

In terms of builtwith.appwrite.io, many of the submissions are from students and junior devs. Many from hackathons.

Again, thanks for the support, we appreciate it, and we're working hard to improve Appwrite!

[wiledal]

Thank you for your answer and understanding. Sorry for coming off strong 🙌. Appwrite is an immense achievement and I look forward to using it. Maybe I'll roll a separate database for now and use Appwrite for everything else, since some of those features are just undeniably tasty 👅.

Of course, it's not fair for me to expect that Appwrite should work specifically to my requirements. I hope my comments here are coming through as suggestions or perspectives more than anything else.

I'll have a gander at the RFC repo! Interesting stuff!

[gewenyu99]

Of course! Team effort. We literally build what the community is most vocal about ;) Helps a ton.

Cheers

[vermakhushboo]

We have created a proposal to add optional server-defined attributes. Would appreciate your feedback here: https://github.com/appwrite/rfc/blob/31c148ccd053be17c9fe86866a92b8760876f824/021-server-defined-attributes.md