There are a couple of use cases where it would be useful to restrict
who can use the API interfaces.

Ezio wants to restrict to developers originally so they can work on
using it perhaps to enhance the web front end. Ralf wants to limit it
to users used for automating specific workflows. This is my guess on
how to handle this.

Add two new config entries:

      xmlrpc_allowed_role
      rest_allowed_role

which are strings that name the role that must be present for the user
to use that endpoint. If the values are empty anybody can use the
corresponding endpoint. Otherwise the user must have the listed role.

Setting:

  xmlrpc_allowed_role = User
  rest_allowed_role = User
  enable_xmlrpc = yes
  enable_rest = yes

would allow any authenticated user access (assuming all non-anonymous
users have the User role). If you don't want to piggyback access on an
existing role, create a new role Rest_User and use:

  xmlrpc_allowed_role = 
  rest_allowed_role = Rest_User
  enable_xmlrpc = no
  enable_rest = yes

to disable all xmlrpc access, allow rest access only for users with
Rest_User role.

For Ezio's use case,

  xmlrpc_allowed_role = 
  rest_allowed_role = Developer
  enable_xmlrpc = no
  enable_rest = yes

should do the trick.

Ralf suggested making the default value 'User' so authenticated users
would be able to use the rest interface This would prevent users who
are not logged in from using the api's. It prevents using the API to
scrape the tracker without login.

If the web interface uses rest this would be an issue for non-logged
in users.  If it can't be coded around (e.g. rest may be used for
progressive enhancement/additional functionality only), the admin
would have to set the value to empty.

Open question, if the value is unset in the config file will the 
default
value be substituted by the current config file processing code?

On IRC Ezio suggested using new permissions that could be added via the 
schema.

Cut/Paste:

(2019-09-13 18:12:40) Taggnostr4: rouilj, what about having different 
permissions for the rest api directly in schema.py?
(2019-09-13 18:13:37) Taggnostr4: something like "View-REST" "Edit-
REST" and similar
(2019-09-13 18:15:06) Taggnostr4: for example, what if I want a 
specific bot to be able to access/edit/remove certain data?
(2019-09-13 18:15:40) Taggnostr4: I guess one way would be giving it a 
specific role and generic view/edit permissions and those should apply 
to the rest api too
(2019-09-13 18:18:07) Taggnostr4: there might be use cases where e.g. 
the user should be able to create issues through the web interface, but 
not through the rest api, but should be able to read both from both 
places
(2019-09-13 18:20:33) Taggnostr4: or we might want to prevent access to 
user emails through the rest api but allow it from the web interface
(2019-09-13 18:30:44) Taggnostr4: I'm going afk and fly back home 
tomorrow, but if you write Taggnostr will read once he gets back :)
(2019-09-13 18:31:08) Taggnostr4 left the room (quit: ).
(2019-09-13 19:52:27) rouilj: Taggnostr, so set up a new set of 
permissions like Web Access: Rest Access, XMLRPC Access?
(2019-09-13 19:58:37) rouilj: then you just add those to the User role, 
or create a new role. Yeah that may make more sense. Have to make sure 
Admin gets all the permissions, but that's doable.
(2019-09-13 20:00:38) rouilj: I wonder if that means we do away with 
the on/off config flags for rest and xmlrpc interfaces.... since there 
is no email on/off (or web on-off for that matter)


In this exchange, my response isn't quite enough, but I think Ezio 
could use it. For the user:

  set up a permission that includes rest access and edit rights for
    some fields. Assign this to a role can_change_status_via_rest.

I am not sure if this makes things more complex, e.g. you would need to 
duplicate read access rights from the web interface.

I added new permissions in rev5879:94a7669677ae they are:

  Rest Access
  Xmlrpc Access

to cgi/client.py.

Adding entries to schema.py like:

  db.security.addPermissionToRole('User', 'Rest Access')
  db.security.addPermissionToRole('User', 'Xmlrpc Access')

will permit the User role to use the xmlrpc and rest APIs.

Looking at handle_xmlrpc, it looks like error conditions
were not properly reported. I made some changes that seem to work,
but it could use another set of eyes.

I am going to declare success on this.

Upgrading mentions needing to add the xmlrpc access perm. Rest perms are 
mentioned in rest.txt.

If there are issues discovered during the 2.0.0 pre-release phase we can 
open new tickets and work them then.