Ability to Disable any of Appwrite's Service

[lohanidamodar]

With upcoming version of Appwrite, we are planning to provide an option to disable any of Appwrite's service. As you can see in the image below.

Right now when you disable a service, you will not be able to access the service and it's functionalities from both server (authenticated with API Key) and client side and the service and it's functionalities are only accessible from the Appwrite's console.

We would like your feedback on the following.

1. 🚀 Should disabling a service disable both on server and client side?
2. 👍🏻 Should it only always disable on the client side and server side shouldn't be affected?
3. ❤️ Should there be options to disable service (that are available on both client and server) separately on client and server so that you can choose to disable either one or both?

Please provide your valuable comments. You can also vote with Emojis 😄
Thank you 🙏🏻

[lohanidamodar]

Personally, I'm about more possibilities, and I think we should have options to choose whether to disable on client or server or both, this might open up more possibilities and use cases we might not know yet. As we want to enable as much power as possible, and yet keep the project aligned to the requirements of your community, we would appreciate all your valuable feedback.

[eldadfux]

I think having all options will add more complexity and uncertainty about how this feature work or why is it useful. That said, disabling server side access seems redundant because it is limited to the API key from the first place. I do see a lot of value in disabling client side access for services that are not actively used by the application.

[christyjacob4]

I'm not seeing much value with the added customisation we're trying to offer. It would only get harder to explain this high level of customisation.

These questions arise when I think about this feature

1. Why would we need to specifically disable client side access ?
2. Don't you think this depends on how the developer decides to write their code ? If I don't want my android app's users to access the teams service, I won't include a teams.createMembersip() [or other)] function call in my app.

Thoughts ?

[mbos2]

What if, on top of this customization, you could create administration teams through permissions in order to create different kind of project/application administration?
For example

• Super administrator - can access all services
• Admin 1 - Can access Database only
• Admin 2 - Can access Users and Database
  . . . These could be customized by Project owner

There could be a team generated when project is created, just for this. Something like Admin team (special team :D)
It would require authentication to access services for administration user has access to.

Making custom administration panels for apps might be simpler with this kind of a feature. This would also apply to projects console (if administrator does not have access to database for example, service would either be hidden or disabled in UI)

This was just on top of my head, it requires more discussion and consideration tho.

[lohanidamodar]

I'm more convinced with @eldadfux that disabling server side access might be redundant.
regarding your suggestion @mbos2, the role based access is something we are discussing for use case like this (#2317) and may be providing limited access to project member as you suggest and can be a separate topic for more ideas and discussion.

[eldadfux]

Agree with @lohanidamodar, role based admin can be discussed as a separate topic. We have started talking about it briefly for the cloud solution, but should definitely have a bigger discussion around it.

[eldadfux]

I'm not seeing much value with the added customisation we're trying to offer. It would only get harder to explain this high level of customisation.

These questions arise when I think about this feature

1. Why would we need to specifically disable client side access ?
2. Don't you think this depends on how the developer decides to write their code ? If I don't want my android app's users to access the teams service, I won't include a teams.createMembersip() [or other)] function call in my app.

Thoughts ?

@christyjacob4 the main usage I see behind this new feature is to avoid a service being abused by a user who knows how to use the Appwrite API.

[JaviBonilla]

When I saw this announcement on Discord I directly thought disabled everywhere, I didn’t even consider that it would be client or server side, which maybe useful in some edge cases but adds complexity.

A question that maybe basic, but what’s the main goal of this? Improve security? Save resources in the server by stopping Docker containers?

[eldadfux]

This is not designed for stopping server containers, because Appwrite containers are separated by functionality and not actual services. For example the Appwrite main container uses as the HTTP API layer for all services.

The main idea behind this was initially to avoid client usage of services you don't need in your project to avoid extra usage. In the server this is not required because you have full control over which services are used using the API key scopes, and your code is only accessible by authorized parties.

[eldadfux]

After thinking more and more about this. I'm pretty sure we should limit this feature to the client API only. Devs have full control on what happens on both server and functions using the API key scopes and their own source-code, no reason to block it from the server side, just like we don't block it from the Appwrite console.

[stnguyen90]

Issue and PR.

[eldadfux]

This feature now effects client side only! If you still want to use any disabled service using the server API, just create an API key with correct scopes.

#3270

[ghost]

It's exactly as someone mentioned up there. The featur is needed to prevent users who know how to use appwrite from doing whatever they want on the client. I for example didn't want to use the permission system built around the team API, but still wanted to use it. I just wanted a custom way of managing roles, and I'll be managing all of that server side. I then needed a way to prevent users on the client from creating teams, and updating them however they wish, because based on my app structure, not just any user can create a team. So, it's good that this feature was added.

Just saying in case someone wanted to see a use case.