La granulariad, las APIs, y un proxy para solucionarlo
A veces las APIs (estoy pensando que existe una analogíca ‘clásica’ con los gestores de bases de datos) no nos proporcionan suficiente granularidad a la hora de gestionar los activos digitales (en los gestores de bases de datos suele haber la granularidad, pero no siempre querremos dedicar tiempo a configurar nuestros programas y, además, los permisos de las bases de datos; seguramente un error, pero es lo que se hace a veces).
Sobre este tema y cómo lo gestionaron en su caso nos habla ‘Statgirl Flowers’ en Building a stateless API proxy:
It turns out GitHub’s API has extremely coarse access control on API tokens. For example, imagine if you wanted to write an editor plug-in to turn your Gists into easily-accessible snippets in your editor. People would have to grant your plug-in write access even though it only really needs read access. There’s a big Dear GitHub post on the subject, but this is not uncommon - many APIs have permissions systems that don’t quite always fit the needs of users.
La solución pasa por crear un proxy donde se gestionan los permisos y qué cosas pueden hacer unos programas y otros no.
So what I really want is a token that can read but not write gists. The proxy can issue its own token. It can keep track of the fact that the token is only allowed to read Gists and not write them. When it gets a request for the GitHub API it can check permissions before forwarding the request and the real token to GitHub.
Curioso.