Authentication through Personal Access Token creates organisational coupling
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
- Issue-Typ
- Feature
- Klarheit
- Muss geklärt werden
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- azure, python
- Bereich
- api, authentication, cloud
Rechercherichtung
Beginnen Sie mit der Überprüfung der dokumentierten Personal Access Token-Authentifizierung der Bibliothek sowie der von Azure DevOps Server unterstützten OAuth2- oder Anwendungs-Authentifizierungsabläufe. Vergleichen Sie die Anforderungen von H2M und M2M und definieren Sie anschließend den unterstützten Ablauf, den Lebenszyklus der Zugangsdaten sowie die erforderliche Dokumentation oder die erforderlichen Tests, um den Abschluss nachzuweisen.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Currently, the only documented way to use this library is to authenticate with a Personal Access Token.
This seems wrong, as:
- From what I know about them, Personal Access Tokens are associated to human accounts
This means an application access to an Azure DevOps instance is tightly coupled to the existence of a human person in an organisation, which means applications access will break depending on other life cycles. - Personal Access Token also require an expiration date, meaning applications access will break regularly, forcing some manual (human) extra credentials management on top of, and separate from, the one associated with the parent account.
Is there a plan to support other kinds of authentication scheme with Azure DevOps (Server)?
One could think of an OAuth2 process, for instance, allowing different flows:
- H2M, much like what is achieved through PAT, without any extra (token, on top of account), manual, token lifecycle management
- M2M which would allow managing applications-specific secrets
Both flow isolate authentication of the application from any other organisational resource, and allow delegation of authorisation and grants lifecycle to a dedicated, potentially automated third-party.
- Vorherrschende Sprache
- Python
- Sterne
- 684
- Forks
- 218
- Ø Merge
- 8 T. 10 Std.
- Gemergte PRs (30 T.)
- 1
Entwicklungsumgebung
Die Einrichtungsdateien dieses Projekts haben wir noch nicht geprüft. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus microsoft/azure-devops-python-api
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 55/100
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 55/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100
Alle Issues in microsoft/azure-devops-python-api
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
gradio-app/gradio#13895 ·
Maintainer antworten meist innerhalb von 1 Tag
-
build-error
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
spack/spack-packages#6713 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Use issue templatesOffen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
ActivityWatch/activitywatch#1464 · 1 Reaktion ·
Maintainer antworten meist innerhalb von 1 Tag
-
[Bug]: The ckg tool drops the return type of every decorated Python method in class search resultsOffen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
bytedance/trae-agent#483 ·
Maintainer antworten meist innerhalb von 1 Tag