Replies: 10 comments 26 replies
-
|
Well, I'm a big fan of Firebase's permissions system. I haven't done any really big projects with it yet, but it always seemed more intuitive and flexible than AppWrite. With Firebase, the backend determines the permissions and you can change the rules universally without having to change the permissions of all files or documents individually. You set the rules here mainly on the structure, which AppWrite currently does not have in this complexity. But you could achieve something similar in AppWrite by assigning "tags" to documents when they are created, like permissions currently are. Based on these tags, the backend could then determine who is allowed to access them. Of course, you would then also have to regulate who is allowed to create which tags. I would not be such a big friend of invitations to permissions, even if it probably fits better into the current system and approach of AppWrite. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I am an Appwrite user from versions 0.5 - 0.6 onwards. Actually the permissions system has seemed to me correct and easy to implement, the problem is the constant change of paradigm when changing versions, this causes changes that break my applications and I must rewrite them every time I want to update. Let me explain: Example 1: Until version 0.7.0 I could create a document and it was not necessary to resend the permissions in each update of that document, since the permissions were saved; but, in version 0.7.1 this changed, and from that version it was necessary to send again all the permissions in each update request; this obviously broke my applications and I had to rewrite the web part and the mobile part. Now, in version 0.12, this change was reverted and the permissions are again saved and are not needed at every update. Example 2: Until version 0.11 I could assign permissions at will from the Account endpoint, that is, in my applications I have administration modules and end customer modules, well, from the administration module I could assign permissions to each document for those end customers using only the Account endpoint. With version 0.12 all this changed and now to do the same process I have to create cloud functions or do it all from the backend. These changes obviously break all my applications and it is necessary to relearn how the permissions and assignments process works. Example 3: Until version 0.10 when a team membership was created, the user immediately had the permissions even without accepting his invitation to the team or validating it. In version 0.11 the permissions are effective until the user accepts the invitation to the team and this is sometimes difficult because some emails go to spam or simply get lost, and the user could not use the application until he validated his membership. I think the current problem is that there is no consensus on how the permissions issue is supposed to work, because as of today, I do not know whether to update my versions of Appwrite to 0.12 by modifying all the code again, because I do not know if in version 0.13 or 0.14 the paradigm will change again and my applications will break again and I will have to do everything again. I am not a big fan of the issue of invitations in the permissions, for an application such as a social network is fine, but, for example, for the applications that I have created that are for business use, it is not very well seen that every time you want to update the permissions of a document users must authorize or accept them. Imagine an inventory system where every time an object is assigned to a user, the user must accept it. Firebase sometimes changes its sdks and generate changes that break my applications, but they are not exaggerated changes, like the permissions issue, they are usually resolved in a couple of hours. Their rules system is a paradigm that doesn't fluctuate, you know exactly what to expect from their permissions system and you know how it works at every instant of time and every update. I would love to help with debugging and reviewing versions together with the team, but unfortunately I need that time to survive in this part of the world π I love Appwrite, its philosophy, its way of implementation and the possibilities I have as a developer implementing it in my applications. The problem is that if every time a new version is released I have to rewrite my app, in 1 year I will be like the doc of "back to the future" π₯Ί. |
Beta Was this translation helpful? Give feedback.
-
|
The great thing about open source is that you can contribute it with new changes ;) |
Beta Was this translation helpful? Give feedback.
-
|
Hi guys, I am loving Appwrite because it is making my backend work easy since I am working on my project in my spare time. I have some issues with the fact that you can't add more roles to your project using the Appwrite console or API, which is somewhat disappointing for me because my options have been narrowed to use teams. Team is not working the way I want it to be. For example, for each user, you invite to a team you will have to assign roles that are not convenient in my case. It will be great to have some user's API endpoints for Imagine you have a pro subscription service, now each time a user subscribes to pro you will have to invite them to the pro team and the day their subscription expires you have to remove them. I know you can achieve this using the backend SDK with cloud functions but that couldn't be compared to an easier alternative that will require you to just update user's roles. |
Beta Was this translation helpful? Give feedback.
-
One thing I see is, when using document level permission, itβs possible to create a document with Consider a multi tenant/saas to do app. A user can:
However, they can also create a to do with |
Beta Was this translation helpful? Give feedback.
-
|
Hi guys, I am very happy with the new permission features. It gives way more control, although I have some improvement requests. At this moment you can only get documents which you can read. It would be massive to get documents which only you have write permission. An example is a collection of user images, where everybody can see the userimage but only you are the author of the image. Especially with Realtime I want to listen to changes in the collection of images you created. Second, I am missing features to use Realtime based on querying. I would like to listen to a custom query, instead of the permission level. Best regards, |
Beta Was this translation helpful? Give feedback.
-
|
Hello, What progress do we have on this issue? is it possible that we will have something like in version 0.11? or definitely that will not be the way anymore? I have some servers that I want to upgrade but it is necessary for me to know how to proceed with the permissions issue. Greetings to all the team. |
Beta Was this translation helpful? Give feedback.
-
|
Hello! Is it possible to have "owner" permissions ? Something that Firebase have: And supabase also support such kind of rules: It's really useful in some cases to have permissions for write to owner |
Beta Was this translation helpful? Give feedback.
-
@collection.users.subscriptionType = "PRO" &&
(@request.auth.id = @collection.posts.createdBy ||
@collection.posts.editableByAnyone = true)Please take a look how Pocketbase implemented permission. It seems very customisable and yet very simple to define. In this example I'm checking if the user has a "PRO" tier and also if authenticated user's ID matches with the post creator's ID or if this post is marked to be editable by anyone. Guys please give your opinions what you think. |
Beta Was this translation helpful? Give feedback.
-
|
#7254 does this bug also because there is some decision pending here on permissions? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Appwrite's permissions make your application secure by default. This means, nothing is allowed by default, and you explicitly need to mention specific users or groups of users, and give them read or write access to specific document or collection. Such a whitelist system makes every Appwrite application secure, and the only security issue can come from the developer's mistakes.
This flow is really handy to keep things secure, but it can become a bit annoying the more you need to customize it. For example, for security reasons, Appwrite cannot allow you to give read permission to other people. This is the case because you could create a bunch of documents, give read access to some users, and spam their (for example) notification feeds. How do you create notifications then? To get around these limitations, you need to prepare cloud functions which can feel time-consuming. All want to do is send some notification, right?!?
Since you are sending notifications from the server-side anyway, this would be fine... But we would hit the same problems if we were building a Figma clone and we wanted to give specific users permissions to our Figma file... Since we can't give them read and write permissions directly from the client, we would need to prepare a cloud function to do that from the server-side. By doing that, we are skipping permissions check, so we aren't really solving the problem, we are just finding a way around it... The main idea here is that the user should have an option to accept or decline the invitation to be part of your Figma file, otherwise you would invite them to every one of your files and if they look at the section "My files", they would see a bunch of your files that they never agreed to be part of.
Our idea to solve these issues is to create Permissions API. Such an API would be used to set permissions for files and documents, and would allow you to give anyone read or write permission to your stuff. Before the permission is applied on a file/document, the subject of the permission change (user you want to give read permission to) will get an invitation and can either accept it, decline it, or potentially block you to automatically decline all future invitations from you.
This is how the flow of our Figma example could look like:
Let's Chat! How what do you think about our idea of
PermissionsAPI? Would you benefit from this feature? Can you see another solution to this problem, or scenario when this would not solve the issue?Beta Was this translation helpful? Give feedback.
All reactions