2014-10-15 12 views
24

caso d'uso:GitHub OAuth2 Token: come limitare l'accesso a leggere un singolo repository privato

  1. applicazione a linea di comando (che viene distribuito ad una macchina 3a parte) deve essere in grado di scaricare un tarball copia di un repository privato appartenente a un'organizzazione tramite GitHub API (v3)

  2. L'applicazione deve essere in grado di accedere a questo solo repository privato e nessun altro repository con autorizzazione di sola lettura.

sono stato in grado di realizzare (1) con la creazione di un'autorizzazione per l'applicazione dopo la registrazione di un client_id/segreto sul mio conto GitHub. Tuttavia, non sembra che i token restituiti dall'autorizzazione consentano l'accesso in sola lettura al repository né siano limitati a un repository (ad esempio, uno potrebbe potenzialmente utilizzare il token per modificare questo repository insieme ad altri appartenenti all'organizzazione).

È possibile limitare l'accesso tramite l'ambito appropriato? Non vedo nulla di rilevante nei documenti API (https://developer.github.com/v3/oauth/#scopes).

+1

Sarei interessato anche a qualcosa di simile, meno il vincolo di sola lettura. L'unica cosa che sembrava pertinente era la distribuzione delle chiavi che puoi creare per un repository, ma non sono sicuro che tu possa usarle tramite l'API. Sembra che l'unica soluzione possibile sarebbe aggiungere un utente fittizio che usi per accedere all'API come collaboratore di quel repository. –

risposta

14

Non credo che sia possibile limitare i token Github OAuth in questo modo. Il github docs for OAuth dicono che

Mentre Git su HTTP con OAuth riduce l'attrito per alcuni tipi di applicazioni, tenere presente che a differenza distribuire chiavi, token OAuth funzionano per qualsiasi repository per cui l'utente ha accesso.

Così, mentre è possibile limitare l'ambito del token in termini di tipi di attività, non si può limitare a un sottoinsieme di pronti contro termine.

Deploy keys può essere limitato a un unico repository, ma consentire l'accesso in scrittura.

La tattica ovvia (come menzionato da Thomas) è creare un account fittizio che rappresenti l'applicazione. Dato l'obiettivo di OAuth, questo potrebbe essere un flusso di lavoro migliore in ogni caso: ti permetterà di modificare facilmente le autorizzazioni che l'app ha come se fosse in realtà un utente.

Github menziona/sostiene anche questa strategia in modo esplicito, chiamandoli machine users.

+0

Mentre funziona, non è conveniente per un'organizzazione poiché non è possibile revocare un token per un utente specifico. –

+1

Le chiavi di distribuzione sono di sola lettura/pull-only, facoltativamente puoi dare loro anche accesso in scrittura/push. – nooitaf

Problemi correlati