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.
-
|
No harm feelings at all, unlike closed-source products this feedback and discussion helps us make Appwrite and open-source products in general so much better. We're always open to hear what the community and other Appwriters think, and how they use Appwrite vs other tools. The all reason for this implementation idea is because we're listening to your amazing feedback. This discussion started as a follow up review we had internally in response to this issue: #2569 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the quick reply :) |
Beta Was this translation helpful? Give feedback.
-
|
The files read and write permissions are handled the same way. Collection level permission should help you decide which user can create specific content. In Appwrite 0.13 storage will have bucket level permission similar to collection level permissions. The new Permissions API is not intended for sending email invites, but rather create an |
Beta Was this translation helpful? Give feedback.
-
|
I know that reading and updating are traded the same, but creating content just isn't. You can upload anything you want to the storage. |
Beta Was this translation helpful? Give feedback.
-
|
We hope to release in a few weeks max, hopefully very soon. |
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.
-
|
This is great feedback. We definitely don't want to introduce breaking changes version after version for much longer, and once reaching version 1.0 our plan is to not introduce this changes without easy backward compatible way, or push them to Appwrite 2.0 branch that will be opened in the future. Its very important to emphasize that the change described here is not a breaking change, it's an addition to support more flexibility with the current design. Today a user of your app is not allowed to add a document with permissions he don't own (example: user:[another_user_id]). The permission API concept, or sharing API if it makes more sense, will be to add new endpoints that allow you to add permissions for roles you don't own with the acceptance of the role owner. This will allow easy sharing of document which can result in an easy way to create collaboration features in your app like a secure chat between users, or live document editing. |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone! I just have the exact same problem with my implementation. I'm building a chat app and I'm creating a document per every chat message. As you guess I need that the destination user have access to the document. As the current implementation I can't do that unless either I create a team or use the server side SDK. Another approach would be create a collection per chat but the user API cannot create collections either... So I'm stuck. I think that allowing that a user can grant access to another user (without invitations, etc.) should be the way to go. Maybe create a third type of permissions? Currently there is Collection-Level, Document-Level and maybe another one less restrictive? So far I'm loving Appwrite but if I'm struggling with this issue... :-/ Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Hi there ! I agree 100% as I am facing the exact same problem. Why can't a user who has permission on his document grant permission to whoever he wants?? It would definitely help a lot and simplify the management of data. Could that be implemented ? |
Beta Was this translation helpful? Give feedback.
-
I sincerely believe that this would be the most appropriate approach. If I create a document, I should be free to decide who I can grant permissions to. Now, there can be a selector mode where the developer decides how he wants to handle permissions, if he wants to do it this way or through the permissions API that @eldadfux mentions. In the end the developer is the one who knows how his project will work and must make this decision. It could be a selection directly from the console where you add the method of assigning permissions. I think it is important to start defining this paradigm, that is, if there will be any change in this section, or if we should definitely make use of cloud functions or the server SDK. In my case, I have projects in production that I have to upgrade to newer versions and this situation has me stuck. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Fabian, Just to let you know that I managed to do this using an appwrite function. Indeed, if you used appwrite command to create a document on server side (not on client side), then you can give permission to several users at the same time. |
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.
-
|
I also think (as seen in my comment above) that permissions are too limited. You are pushed too much into this scheme, which by far does not always fit. Personally, I would actually like to have the possibility to write this logic myself. Then you could also use the database to determine whether someone has access, and not necessarily have to use the permissions. This would not change the default behavior of the permissions, but only make them more flexible for advanced users. In addition, you could then also assign rights to create content, so that e.g. not everyone can upload files as he wants. Currently you can only create a function to delete files afterwards. Or do everything via functions, which makes the permission system overdue. |
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.
-
|
0.11 I think there was combination btn Collection and Document Levels .. it was great to set all collection write permission ( as I think it was working ) then you can specifiy every document read permission and write .. ( not sure it was working like that to be honest but it can be a solution in feature updates ) .. it's annoying that people can control your backend and create documents and u can't prevent them so what is the logic then it can break ur app if u depend on indexes .. people can create random files with read:all permission .. if u depend that screen on ur app will load depending on document[0] .. that will Break your app for all newly users who must load document[0] that they have read access to as there is already a document with role:all |
Beta Was this translation helpful? Give feedback.
-
|
I think this can be alleviated with more permissions than just read and write. If write was separated into create, update, and delete, you can restrict the creation and deletion of documents, while still allowing updates. Separating read permission into list and view would be helpful too. For example, I may not want users to be able to list all files in my bucket, but only view the ones they know the ID of. This would make it harder for people to scrape all my files. |
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.
-
|
Hi!
How can I do it now? I tried many options and nothing worked. |
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.
-
|
Did you find any solution? Thanks! |
Beta Was this translation helpful? Give feedback.
-
There is no solution out of the box. You can achieve something similar using cloud functions and check everything there, but it's not convenient... |
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.
-
|
I personally use pocketbase right now, but appwrite has looked like a very valuable alternative. The way functions are set up is what is drawing me to appwrite. The permissions are harder for me to understand and seem more complicated than they need to be though. That is the only reason I have not switched over. Pocketbase uses document level protection with easy customization. |
Beta Was this translation helpful? Give feedback.
-
|
+1 I'm also a huge fan of the permission handling in pocketbase! Super powerful but also super simple :) |
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