Topic on Project:Support desk

According to the relative documentation the writeapi user permission enables the groups with that permission (*, user, bot) to use the write API.

The write API includes modules like Delete for example for deletion of pages.

The delete permission is set to true for the sysop group, but is not set at all for the * group in the DefaultSettings.php file. Despite the fact that the writeapi permission is enabled for the unregistered users and the fact that the delete permission is not defined for them, deleting a page through the write API is not possible for users that aren't logged in.

My question is which permissions does actually the writeapi permission give to the groups to which is assigned or in other words what does block the execution of a delete request through the API for the unregistered users?

honestly, i thought we were getting rid of the writeapi permission. It doesn't really do all that much useful and breaks mediawiki if you take it away.

Any permission not defined for a group is the same as false.

I think you're also fundamentally misunderstanding the `writeapi` permission. It does not grant people ability to carry-out privileged action associated with each and every api module.

It only allows write access via the api endpoint. But each individual module will do its permission checks and only users with the required permission will be allowed to carry-out the action. The required permissions are the same as used via the web ui. So if you don't have 'delete' permission via the web, you'll definitely not have it via the api either. The same thing applies for every other permission.

@Ammarpad

Since there are permission checks for each end every module, what's the point of having a permission called "writreapi"? If a certain permission is given to a group like "edit" or "rollback" for example, that should automatically mean that the users of this group have all the required rights to perform these actions also by using the API.

Point of permission is to control write action via the api. Even though same permissions as on the web are required for each individual action, api entry point have capability to allow users to do (or abuse) things in incredible ways.

If a certain permission is given to a group like "edit" or "rollback" for example, that should automatically mean that the users of this group have all the required rights to perform these actions also by using the API.

That's already the case and I have mentioned that above.

Point of permission is to control write action via the api. Even though same permissions as on the web are required for each individual action, api entry point have capability to allow users to do (or abuse) things in incredible ways.

Well, that's what made me start this thread. I have a wiki that allows editing only to registered users and as an extra security measure I had disabled the writeapi permission for the * group. That had as a result a 403 error by the VisualEditor and unfortunately it is not possible to give the writeapi permission specifically to the VisualEditor.

It was suggested to me though that disabling the writeapi does not really offer any extra security as the writeapi performs the same permission checks as the web interface.

So that's the critical question: Does keeping the writeapi enabled increases in any way the security risk or does the fact that the same permission checks are performed for every action, practically means that disabling the API does not offer any real benefit?

That's already the case and I have mentioned it above

When I say automatically, I mean without explicitly controlling it. In other words to remove such a permission and just keep the others.

restricting write api does not offer any security benefits. There is basically zero reasons to ever revoke that right (which is why i think it should be removed from mediawiki)

@Bawolff

well, my initial impression was that the writeapi permission was offering certain groups the ability to use all of the write API's modules independently of other permissions. Obviously, that's not the case. If users can't perform an action through the web interface, then they can't perform it neither by using the API. For example users without the edit permission can't use the edit module of the API to make an edit.

I see only one possible case for the writeapi permission to exist. Is there a possibility for users that have the edit permission to perform more actions through the API compared to the web interface? For example the edit module has a bot parameter. Could a user who has the edit permission set it to true, despite the fact that we talk about a human user?

If the later is true then maybe there is a reason for existence for the writeapi permission, not for users who don't have certain rights, but for the ones they have those rights, as a measure of preventing extra configuration that are only possible via the API.

If that's not true, then indeed it offers nothing except a little bit extra confusion and as a result it should be removed.

no that's not possible.

Original motivation was more around preventing easy data exfiltration and protection against performance issues if a bug is found, when the api was first develped. It became less and less relavent as time went on.