Permisos

Una llave lleva un conjunto de permisos, y una petición fuera de ese conjunto se rechaza antes de llegar a la base de datos. Pide los menos que resuelvan: una llave es más fácil de entregar, y más barata de perder, cuando puede menos.

Los permisos se llaman <recurso>.<read|write>. El conjunto que una llave puede tener es una constraint en la base de datos, y no una lista en el código, así que un permiso que no existe no puede guardarse por ningún camino, incluido uno escrito después que se olvide de comprobar.

Ausentes a propósito

• Sin permiso de moderación. El poder de moderador no se delega a una llave.
• Sin borrado de cuenta. Eso pasa por segundo factor y confirmación escrita, y una llave no es ninguno de los dos.
• Nada alcanza los datos privados de otra cuenta. social.read devuelve a quién sigue el dueño, no lo que esas personas tienen.
• Sin permiso de Arcade. En esta fase ningún permiso abre Arcade a una llave. El identify de Arcade es el consentimiento de un jugador dentro del SDK, no un permiso de llave.

catalog.read es distinto

Es el único permiso que no toca los datos de nadie, y el que la mayoría de las integraciones realmente quiere. Funciona en una llave que no tiene nada más, que es la llave correcta para un bot que solo consulta juegos.

La única excepción son los filtros de la búsqueda sobre los juegos del propio dueño (played, library, unplayed, wishlist y hideIgnored en GET /api/v1/games): leen la biblioteca, así que piden también library.read. Sin ellos, la búsqueda no toca nada de nadie.