Change Details

The `writeapi` permission controls whether one is allowed to use action API endpoints which do some kind of write. This is not terribly useful: * By default it's given to all users, even anonymous ones. * Write permission handling is somewhat mixed up with write performance handling (ie. whether the API does DB writes) and as a result all kinds of conceptually non-write APIs require this permission. ** Specifically, the login API requires it, so revoking it from anonymous users makes the site unusable unless it uses some very atypical authentication method. * All actions that actually change something have their own user rights so `writeapi` isn't really needed for access control. * `writeapi` check are applied at the API endpoints, so usually they can be circumvented by performing the same action via the web interface. Requiring `writeapi` for login is a recent change ({T283394}) necessitated by the coupling of write permission flags and write performance flags. A bunch of third-party wikis disabled `writeapi` for anonymous users; there is not much point to that, but the documentation kind of implied it's a useful thing to do (e.g. [[https://www.mediawiki.org/wiki/API:Restricting_API_usage#Restricting_access_to_the_write_API|here]]) and it didn't break anything. But with the change to login APIs, it does break a lot of things, so let's get rid of it and turn `Rest\Handler::isWriteAllowed()` and similar into performance-only flags. A possible counterargument would be that those flags come in pairs (e.g. with ``Rest\Handler::isReadAllowed()`) and the read flag is meaningful for permission handling - there is no `readapi` right, just `read`, and that is used as the main access control mechanism for all kinds of things. So having those flags fulfill different functions would be unintuitive.

The `writeapi` permission controls whether one is allowed to use action API endpoints which do some kind of write. This is not terribly useful: * By default it's given to all users, even anonymous ones. * Write permission handling is somewhat mixed up with write performance handling (ie. whether the API does DB writes) and as a result all kinds of conceptually non-write APIs require this permission. ** Specifically, the login API requires it, so revoking it from anonymous users makes the site unusable unless it uses some very atypical authentication method. * All actions that actually change something have their own user rights so `writeapi` isn't really needed for access control. * `writeapi` check are applied at the API endpoints, so usually they can be circumvented by performing the same action via the web interface. Requiring `writeapi` for login is a recent change ({T283394}) necessitated by the coupling of write permission flags and write performance flags. A bunch of third-party wikis disabled `writeapi` for anonymous users; there is not much point to that, but the documentation kind of implied it's a useful thing to do (e.g. [[https://www.mediawiki.org/wiki/API:Restricting_API_usage#Restricting_access_to_the_write_API|here]]) and it didn't break anything. But with the change to login APIs, it does break a lot of things, so let's get rid of it and turn `Rest\Handler::isWriteAllowed()` and similar into performance-only flags. A possible counterargument would be that those flags come in pairs (e.g. with `Rest\Handler::isReadAllowed()`) and the read flag is meaningful for permission handling - there is no `readapi` right, just `read`, and that is used as the main access control mechanism for all kinds of things. So having those flags fulfill different functions would be unintuitive.

The `writeapi` permission controls whether one is allowed to use action API endpoints which do some kind of write. This is not terribly useful: * By default it's given to all users, even anonymous ones. * Write permission handling is somewhat mixed up with write performance handling (ie. whether the API does DB writes) and as a result all kinds of conceptually non-write APIs require this permission. ** Specifically, the login API requires it, so revoking it from anonymous users makes the site unusable unless it uses some very atypical authentication method. * All actions that actually change something have their own user rights so `writeapi` isn't really needed for access control. * `writeapi` check are applied at the API endpoints, so usually they can be circumvented by performing the same action via the web interface. Requiring `writeapi` for login is a recent change ({T283394}) necessitated by the coupling of write permission flags and write performance flags. A bunch of third-party wikis disabled `writeapi` for anonymous users; there is not much point to that, but the documentation kind of implied it's a useful thing to do (e.g. [[https://www.mediawiki.org/wiki/API:Restricting_API_usage#Restricting_access_to_the_write_API|here]]) and it didn't break anything. But with the change to login APIs, it does break a lot of things, so let's get rid of it and turn `Rest\Handler::isWriteAllowed()` and similar into performance-only flags. A possible counterargument would be that those flags come in pairs (e.g. with ``Rest\Handler::isReadAllowed()`) and the read flag is meaningful for permission handling - there is no `readapi` right, just `read`, and that is used as the main access control mechanism for all kinds of things. So having those flags fulfill different functions would be unintuitive.