Ho un robot che pubblica sui thread. A volte vorrebbe caricare prima un’immagine e includerla nel post.
Per quanto ne so, non esiste uno scope API che dia accesso a /uploads, quindi devo concedergli l’accesso a tutto.
Sarebbe ragionevole (a) definire uno scope standard per fare questo, o (b) consentire uno scope personalizzato con accesso agli endpoint definiti dall’amministratore?
Ho caricamenti funzionanti (utilizzando l’endpoint /uploads). Ma l’unico modo in cui posso concedere le autorizzazioni della chiave API affinché questo funzioni è concedere tutte le autorizzazioni, il che rappresenta un ovvio rischio per la sicurezza.
Quello che sto chiedendo è uno scope di autorizzazioni API che includa /uploads - se facesse parte di “scrivi post” andrebbe bene per me, ma potrebbero esserci ragioni per renderlo una cosa separata. In alternativa (e probabilmente una buona idea in generale), vorrei poter definire uno scope personalizzato che includa le cose specifiche che desidero consentire.
Beh, non tutti fanno cose così ovvie prima di postare. Mi dispiace! Sembra che almeno un’altra persona (che penserei conosca più di me su questo particolare problema) si aspettasse che uno scope che potesse creare un post potesse anche creare gli upload ad esso associati.
Non ha senso che se una chiave API può creare un post, possa anche creare un upload, proprio come un utente che può creare un post può anche creare un upload?
Ci sono situazioni in cui i caricamenti sono utili al di fuori del contesto di un post? Per quanto ne so, i caricamenti vengono rimossi automaticamente periodicamente se non sono associati a post, quindi rendere possibile l’ambito di una chiave API per il caricamento e non per la creazione/modifica di post non sembra ovviamente utile.
Come ha menzionato @pfaffman, avrebbe più senso se gli ambiti topics:write e posts:edit concedessero l’accesso al caricamento se l’utente associato avesse il permesso di caricare.
Presumibilmente, caricare un nuovo avatar è qualcosa che si potrebbe utilizzare con l’ambito API users:update. (Cosa che attualmente non è possibile?)
Con percorsi più vari e potenziali futuri in cui i caricamenti potrebbero essere utilizzati, ha probabilmente senso creare un ambito separato e porre l’onere all’utente di scegliere l’ambito appropriato. È chiaro per gli utenti quando una chiave API potrà/non potrà caricare ed evita di perdere potenzialmente situazioni in cui i caricamenti potrebbero essere utilizzati se/quando si estenderanno le API.