Meaning of permissions set on a collection

I'll like to ask more about document security and collection permissions in appwrite.

If I set write permission for logged in users on a collection in appwrite, does that mean that any signed in user will be able to create documents in the collection?

What does write permission on a collection/bucket really mean? Does it mean that the role which the permission has been assigned will be able to create/update/delete documents/files as they like from the collection/bucket?

How do the meanings of those permissions change when documentSecurity/fileSecurity is enabled. I'm assuming they don't change at all. Since every access is denied by default.

Write is alias to create+update+delete.

Giving write permission to all users on collection-level is like "admin mode" - it will let all users to create new documents, but also edit or delete all existing ones.

If you use both collection permissions and document permissions, they simply stack. So if collection permissions allow you to do something, document permissions wont override it.

In general its usually only secure to give read or create permissions on collection level to wide variety of users.
Access to manage documents they made should be done with document security

Okay thanks. I figure you might want to add some things to this https://discord.com/channels/564160730845151244/1123704308966379552

I have a suggestion for better approach, but I am not at home right now. Ill write a message there when I get home. The idea is to impersonate client similiarly to how server side rendering would. That way you can trust all Appwrite permission checks even when running queries on server

Yes, I did consider that. But the issue is that those require the user to be signed in with Appwrite's own auth system.

What I'm trying to do there is use an external Auth system with appwrite.

If it was possible to create user sessions directly from the server sdk without the user having to follow appwrite's Auth system, that'll be possible.

The Auth system is a passwordless system that lets users sign in via biometrics and falls back to email magic URL. So, if I could create user's session directly in appwrite, I would just sync the users between the two systems, and swap the session tokens when the user logs in

A thread on that here https://discord.com/channels/564160730845151244/1121333137742495824

You might want to see that thread too

It is possible to create a session on server-side, it's just not part of SDK currently, and you would need to read cookie header to get the session.

Do I understand correctly that output of our external auth system is Appwrite User ID?

Creating a user session involves passing credentials, doesn't it?

In this case, the user is not supposed to log in using credentials they have with appwrite. They'll login using credentials they have with the external Auth system. And when they log in, the session token from that Auth system is swapped with one from appwrite and then used to make calls to appwrite APIs

This also means that a new user will be created in appwrite whenever a user signs up with the external Auth system

Hmm, true. I am working on RFC for custom auth flows. Idea is to create endpoint to generate token from user ID, and endpoint that uses the token to create session. If your case you would run both on server and have the session witout any credentials.

For that to work, I must be able to create user sessions on appwrite from the server without providing credentials (other than email)

It would be great if that would allow passing an email to create the user's session directly without passing credentials. That should be only on the server of course

That way, one can easily swap tokens from any external Auth with appwrite tokens allowing access access to appwrite services based on users account with an external auth system

@Meldiron Two more questions.

• Does appwrite use direct permission to action or not. That is, for example, does a user require read permission to update/delete a document/file? Or just the individual update/delete permission would suffice?

• If a user is only granted update permission on a collection, will they be able to create/delete documents in the collection? I assume no. Am I right?

• If a group have permission only for a update then it will be able to update, but not to read.
• You can see here https://appwrite.io/docs/permissions#permission-types that Permission.update() is a specific one, which means the user can't remove (delete) it.

The first question isn't very clear though.

Please check it once again

Does a user require read permission to carry out update?

And as for the second, it isn't clear too. I know update is specific. But here, I'm talking about update permission on collection, not on document. But I think the answer is no anyway.

Basically, permission on a collection is like setting the permission on all documents in the collection, right?

Yes.

It seems like the user don't need to have the read permission to update. altough it can be a bit odd, as the user won't know what being updated.

Okay. Yeah, it's odd, but it's what has been defined. So,...