Un’idea in questo senso, correlata ad alcuni lavori di definizione degli ambiti di @david, è quella di creare una chiave API utente strettamente limitata a un singolo feed RSS. In questo modo, la superficie di attacco sarebbe ridotta e, in casi come questo, dove disponiamo di una chiave API utente con ambito ultra-restrittivo, potremmo permetterne l’uso senza intestazioni (aggiungendo una colonna su user_api_key per indicare che questa chiave può essere utilizzata per l’autenticazione tramite GET).
Le sfide in questo caso sono:
-
Non abbiamo un meccanismo per generare chiavi API utente; dovremmo crearne uno per il caso d’uso RSS, il che comporterebbe una nuova UX. Non sono sicuro di dove inserirla, forse nel profilo utente, ma non lo so.
-
Non abbiamo un meccanismo per limitare l’ambito a un singolo feed RSS specifico, che dovremmo aggiungere.
-
Non abbiamo un flag per “chiave API utente consentita” tramite parametri GET nell’URL, che sarebbe necessario per questo.
Nel complesso, vedo questo come qualcosa che potremmo risolvere, ma probabilmente dovremmo considerare una o due settimane di lavoro per farlo funzionare perfettamente.
Il vantaggio è che parte di questo lavoro è qualcosa che vorremmo fare indipendentemente da RSS, ma lo svantaggio è che parte del lavoro è strettamente legato a RSS e ci sono pochissime persone che utilizzano questa funzione al giorno d’oggi.
Spetta a @codinghorror decidere come vogliamo dare priorità a questo.