API : une portée avec accès à /uploads

J’ai un robot qui publie sur des fils de discussion. Parfois, il aimerait télécharger une image d’abord, puis l’inclure dans la publication.

Autant que je sache, il n’y a pas de portée d’API qui donne accès à /uploads, je dois donc lui donner accès à tout.

Serait-il raisonnable (a) de définir une portée standard pour faire cela, ou (b) d’autoriser une portée personnalisée avec un accès aux points de terminaison définis par l’administrateur ?

3 « J'aime »

Avez-vous essayé ? Je penserais qu’un utilisateur qui peut poster peut télécharger.

2 « J'aime »

Euh, oui, sinon je n’aurais pas posté ? Plus précisément, cela nécessite le point de terminaison /uploads plutôt que /posts, de sorte que la réponse est 403.

Est-ce que cela est utile ?

1 « J'aime »

Merci, mais pas vraiment.

J’ai des téléchargements qui fonctionnent (en utilisant le point de terminaison /uploads). Mais la seule façon dont je peux accorder des permissions de clé API pour que cela fonctionne est d’accorder toutes les permissions, ce qui représente un risque de sécurité évident.

Ce que je demande, c’est une portée de permissions API qui inclut /uploads - si cela faisait partie de « écrire des articles », cela me conviendrait, mais il pourrait y avoir des raisons d’en faire une chose distincte. À défaut (et probablement une bonne idée en général), j’aimerais pouvoir définir une portée personnalisée qui inclut les éléments spécifiques que je souhaite autoriser.

2 « J'aime »

Avoir une portée pour la création de téléchargements me semble une bonne idée, certainement pr-welcome. La modification pertinente serait par ici :

Ainsi qu’une nouvelle chaîne de traduction ici.

Je pense que cela aurait plus de sens en tant que \"uploads\": \"create\"

@RogerBW es-tu disposé/capable de faire une PR ici ? Si oui, vas-y et poste le lien dans ce sujet.

5 « J'aime »

Eh bien, tout le monde ne fait pas des choses aussi évidentes avant de poster. Désolé pour ça ! Il semble qu’au moins une autre personne (qui, je pense, en sait plus que moi sur ce problème particulier) s’attendait à ce qu’une portée qui peut créer un message puisse également créer les téléversements qui l’accompagnent.

N’est-il pas logique que si une clé d’API peut créer un message, elle puisse également créer un téléversement, tout comme un utilisateur qui peut créer un message peut également créer un téléversement ?

2 « J'aime »

Existe-t-il des situations où les téléchargements sont utiles en dehors du contexte d’une publication ? Si je comprends bien, les téléchargements sont automatiquement supprimés périodiquement s’ils ne sont pas associés à des publications. Par conséquent, permettre de limiter une clé d’API au téléchargement et non à la création/modification de publications ne semble pas manifestement utile.

Comme l’a mentionné @pfaffman, il semblerait plus logique que les scopes topics:write et posts:edit accordent l’accès au téléchargement si l’utilisateur associé a la permission de télécharger.

1 « J'aime »

Oui, je suis à peu près sûr que les avatars utilisent la même route de téléchargement, mais ne sont pas attachés aux publications.

5 « J'aime »

On peut supposer que le téléchargement d’un nouvel avatar est quelque chose que l’on pourrait utiliser avec la portée de l’API users:update. (Ce qui n’est pas possible actuellement ?)

Avec des voies plus variées et potentiellement futures où les téléchargements pourraient être utilisés, il semble judicieux de créer une portée distincte et de laisser à l’utilisateur la responsabilité de choisir la portée appropriée. Il est clair pour les utilisateurs quand une clé d’API pourra/ne pourra pas télécharger et évite de manquer potentiellement des situations où les téléchargements pourraient être utilisés lors de l’extension des API.

1 « J'aime »

C’est fait. Il faudra des tests et autres, mais voici au moins une base.

J’ai utilisé une portée séparée, pour les raisons décrites - je peux certainement voir que je pourrais vouloir autoriser les publications mais pas les téléchargements.

6 « J'aime »

Merci ! J’ai ajouté un commentaire sur GitHub.

5 « J'aime »