Add permissions for API keys

[justinclift]

This is still very much a work in progress. The goal is for people to be able to limit what can be done with their API keys. eg, set permissions

So far, the UI pieces are at the bottom of the user Settings page, and look like this:

While ok for an initial go, it seems like it could become very unwieldy with even just a few API keys. So, the field of on/off boxes and similar might be better moved into a separate page with a button to go there. eg Change permissions or something

List of things:

• [ ] - On/off toggles to select which functions are allowed for a given API key
  • Probably 60-70% done
• [ ] - Database selector, to limit which database(s) an API key is allowed to work on
  • So far, it's "All databases" or "Pick a specific one". That should be good enough to start with
  • Probably 60-70% done
• [ ] - IP address range(s), to limit which IP addresses the API key is allowed to be requested from
  • Pretty sure this will be a good idea for places who know they'll only be requesting from specific addresses. eg a static ip or similar
  • Not yet started
• [ ] - Hook up the API code, to validate the incoming function calls with the chosen permissions
  • Not yet started

[chrisjlocke]

I looked at how MySql does it, as it has to do something similar for database users. Here, it lists each user (or API key in your world) and you modify it independently on its own page.

I'm wondering if a friendly name (which would be a user name?) would be handy - if you had a key garblegarblegarble which did something, would you really know what that was in a month's time? If you could set a friendly name to it, it might help admin-wise ... but then you're maybe going down the route of calling them 'users' and not 'api keys' ... calling them users is more friendly though ... but guess you don't want to rewrite a bunch of code now for no benefit... (sorry - mumbling again...)

[chrisjlocke]

In the MySQL world, you create users then assign them to databases (with the above permissions being configurable for each database). The config screen for this in phpMyAdmin is a bit unwieldy though - initially confusing with 'create user', 'assign to database', 'set permissions' forms everywhere. I like your current approach though - either all or 'just this one'.

[justinclift]

Interesting thought about the friendly name thing. We could definitely add some kind of "friendly name" and/or "notes and comments" field that's free form text for people to use. They'd only be extra data (metadata?) for making things easier to remember though, and wouldn't be used in actual authentication or wherever.

Oh, there's no real need for changing "api keys" to "users". That'd just confuse things. The ability to lock down what an api key can do is the important thing. :smile:

[justinclift]

Oh, this is what the database selection drop down (all databases, or just a specific one) looks like. It's kind of unwieldy when there are a bunch of databases, but I'm thinking it'll do for a first go. :smile:

[LeMoussel]

What kind of error occurs to indicate that function are not allowed for a given API key?

[justinclift]

@LeMoussel So far, I haven't yet written the part of the API code which validates things. eg I've just hooked up the webUI pieces so far, as I had to start somewhere and that helped me think some initial bits through. :wink:

So... what would you like? :smile:

[justinclift]

Oh, an "All permissions" toggle up the top might be nice for people too.

Hmmm, might be better to do that later though. Like, after we've actually worked the problem through end-to-end first and are mostly sure of the shape this should take.

[justinclift]

Finally got those initial on/off permission buttons working ok with multiple api keys on the page. They get saved to and loaded from the backend properly, and show up ok, etc. (ironically, it's the frontend javascript which takes the most time and causes the most frustration)

Things still to do:

• Adjust our API code to make use of these permissions
• Show the api key owner when it was last called. Should help when them knowing if a key is in-use vs old-and-unused, etc
• Add the IP address range permissions pieces
  • Likely do this adding the initial permission checks to the API code
• Add the api key revoking pieces. eg the "Remove this API key" button needs its backend/frontend code written

[MKleusberg]

I had a long look at this PR now and still not quite sure how to best proceed. Especially when adding more API endpoints in the future the UI becomes even more difficult to navigate. In the long run it might be better to have a separate page for defining roles and then reduce the API configuration to setting a role. I'd suggest leaving it open for now but in the meantime I'm preparing a commit that just adds read-only permissions as a new permission level.

[justinclift]

In the long run it might be better to have a separate page for defining roles and then reduce the API configuration to setting a role.

Yeah, that's probably the right approach.

I'd suggest leaving it open for now but in the meantime I'm preparing a commit that just adds read-only permissions as a new permission level.

Been trying that code (with the read only keys in it) out on my local dev system, and it's looking pretty good. :smile: