Tengo un robot que publica en hilos. A veces le gustaría subir una imagen primero e incluirla en la publicación.
Por lo que puedo ver, no hay un ámbito de API que dé acceso a /uploads, así que tengo que darle acceso a todo.
¿Sería razonable (a) definir un ámbito estándar para hacer esto, o (b) permitir un ámbito personalizado con acceso a puntos finales definidos por el administrador?
Tengo las cargas de trabajo funcionando (usando el endpoint /uploads). Pero la única forma en que puedo otorgar permisos de clave de API para que esto funcione es otorgar todos los permisos, lo cual es un riesgo de seguridad obvio.
Lo que estoy pidiendo es un alcance de permisos de API que incluya /uploads; si formara parte de “escribir publicaciones”, estaría bien para mí, pero podría haber razones para hacerlo algo separado. De lo contrario (y probablemente una buena idea en general), me gustaría poder definir un alcance personalizado que incluya las cosas específicas que deseo permitir.
Bueno, ¡no todo el mundo hace cosas tan obvias antes de publicar. ¡Lo siento! Parece que al menos otra persona (que creo que sabe más que yo sobre este tema en particular) esperaba que un ámbito que pudiera crear una publicación también pudiera crear las cargas que la acompañan.
¿No tiene sentido que si una clave de API puede crear una publicación, también pueda crear una carga, al igual que un usuario que puede crear una publicación también puede crear una carga?
¿Hay alguna situación en la que las cargas sean útiles fuera del contexto de una publicación? Según entiendo, las cargas se eliminan automáticamente periódicamente si no están asociadas con publicaciones, por lo que hacer posible el ámbito de una clave de API para cargar y no crear/modificar publicaciones no parece obviamente útil.
Como mencionó @pfaffman, tendría más sentido si los ámbitos topics:write y posts:edit otorgaran acceso para cargar si el usuario asociado tiene permiso para cargar.
Presumiblemente, subir un nuevo avatar es algo que uno podría utilizar con el ámbito de la API users:update. (¿Lo cual no es posible actualmente?)
Con vías más variadas y potenciales en el futuro donde se podrían usar las cargas, probablemente tenga sentido crear un ámbito separado y dejar que el usuario elija el ámbito apropiado. Queda claro para los usuarios cuándo una clave API podrá o no podrá subir y evita perder potencialmente situaciones donde las cargas podrían usarse si/cuando se extiendan las API.