Clone, Push und Zugriffstoken

Störungen zwischen einem gewöhnlichen Git-Client und dem Git-Endpunkt des Wikis.

Umgebung für alle Abschnitte dieser Seite: ein Git-Client beliebiger Art, Anmeldung über HTTP-Basic mit einem persönlichen Zugriffstoken. Die Adresse stammt vom Repository-Bildschirm, Abschnitt Dieses Repository beziehen.

Der Benutzername ist gleichgültig. Der Endpunkt prüft ihn nicht; das Token allein bestimmt die Identität. Es gehört in das Kennwortfeld. Wer nach dem „richtigen„ Benutzernamen sucht, sucht nach etwas, das keine Rolle spielt — und wer sein Wiki-Kennwort einträgt, wird abgewiesen, obwohl es das richtige Kennwort ist.

Die Adresse wird nicht von Hand zusammengesetzt. Sie hängt von der Adresse dieses Wikis und vom Namensraum ab, an dem das Repository eingebunden ist, und wird auf dem Repository-Bildschirm vollständig ausgegeben. Ein Klick in das Feld wählt sie ganz aus. Fast jede Meldung über ein unbekanntes Repository geht auf eine selbst gebaute Adresse zurück.

Die vollständige Anleitung steht unter Repository clonen.

Sie sehen: eine Anmeldeabfrage, die nach jeder Eingabe wiederkommt, und am Ende eine Ausgabe dieser Art:

remote: authentication required
fatal: Authentication failed for 'https://.../git.php/...'

Der Git-Client übersetzt die Antwort des Endpunkts; authentication required ist der Wortlaut, den der Endpunkt selbst sendet, Authentication failed der des Clients. Beide meinen dasselbe.

Umgebung: git clone, git fetch oder git push.

Mögliche Ursache

1. Das Wiki-Kennwort statt eines Tokens eingetragen. Das Wiki-Kennwort gilt am Git-Endpunkt nicht.
2. Das Token ist abgelaufen, zurückgezogen oder falsch kopiert. Ein abgeschnittener Wert sieht aus wie ein falsches Kennwort.
3. Der Client benutzt einen gespeicherten alten Wert. Windows und macOS speichern Zugangsdaten dauerhaft; nach einem Tokenwechsel liefert der Speicher weiter den alten Wert, ohne zu fragen.
4. Anonym, wo es nicht geht. Ohne Zugangsdaten geht ein Clone nur, wenn die Einbindung das ausdrücklich erlaubt. Ein Repository, das im Wiki lesbar ist, muss nicht anonym clonbar sein — das sind zwei verschiedene Stufen.
5. Ein push ohne Anmeldung. Anonym wird nie geschrieben. Der Endpunkt antwortet dann bewusst mit einer Anmeldeaufforderung statt mit einer Ablehnung, damit der Client nach Zugangsdaten fragt.

Prüfen

1. Prüfen Sie, was Sie eingetragen haben: Gehört der Wert in das Kennwortfeld und stammt er aus der Token-Selbstverwaltung?
2. Öffnen Sie die Token-Selbstverwaltung und sehen Sie nach, ob das Token noch besteht und nicht zurückgezogen ist.
3. Leeren Sie den Zugangsdatenspeicher Ihres Betriebssystems für die Adresse dieses Wikis und versuchen Sie es erneut. Erst dann fragt der Client wieder.
4. Prüfen Sie auf dem Repository-Bildschirm die Sichtbarkeit, bevor Sie einen anonymen Clone erwarten.

Lösen

1. Legen Sie ein neues Token an und tragen Sie es in das Kennwortfeld ein; als Benutzername genügt ein beliebiger Wert. Anleitung: Zugriffstoken erstellen.
2. Kopieren Sie den Wert sofort bei der Ausgabe. Er wird genau einmal angezeigt; gespeichert wird nur eine Prüfsumme, aus der ihn niemand zurückrechnen kann — auch die Administration nicht.
3. Räumen Sie den Zugangsdatenspeicher auf, bevor Sie ein neues Token einsetzen.

Eskalieren: Erst, wenn ein frisch angelegtes Token bei geleertem Zugangsdatenspeicher ebenfalls abgewiesen wird. Anfrage an die Administration, Art Administrative Änderung anfordern. Übertragen Sie den Tokenwert nicht — er wird zur Klärung nicht gebraucht. Nennen Sie stattdessen die Bezeichnung des Tokens, den Zeitpunkt und die verwendete Adresse.

Sie sehen: forbidden.

Umgebung: git clone oder git fetch mit gültigem Token.

Mögliche Ursache: Das Token wurde angenommen — Ihre Identität steht fest. Sie erreichen auf diesem Repository aber nicht die Stufe beziehen. Der Unterschied zur vorigen Meldung ist genau dieser: authentication required heißt „ich weiß nicht, wer Sie sind“, forbidden heißt „ich weiß es, und es genügt nicht„.

Ein häufiger Sonderfall: Sie dürfen das Repository im Wiki ansehen, aber nicht beziehen. Beides sind getrennte Stufen; siehe die Stufenleiter unter Projekte, Repositories und gesperrte Seiten.

Prüfen

1. Lesen Sie in der Repository-Tabelle die Spalten Sichtbarkeit und Ihre Rolle.
2. Steht im Abschnitt Dieses Repository beziehen ein Hinweis auf reinen Lesezugriff, ist die Ursache bestätigt.
3. Prüfen Sie, ob Sie das richtige Token benutzen, falls Sie mehrere Konten haben — die Stufe hängt am Konto hinter dem Token.

Lösen: Nicht selbst lösbar. Die Stufe wird vergeben, nicht eingestellt.

Eskalieren: Zugriff anfordern — die Anfrage der Art Zugriff auf Repository anfordern, die die Maintainer des Projekts bearbeiten. Nennen Sie, dass Sie clonen möchten; das benennt die Stufe, um die es geht, ohne dass jemand raten muss.

Sie sehen: unknown repository, oft vom Client übersetzt zu fatal: repository not found.

Umgebung: git clone mit einer selbst eingetippten oder aus einer älteren Quelle übernommenen Adresse.

Mögliche Ursache

1. Die Adresse zeigt auf einen Namensraum, an dem nichts eingebunden ist. Vertippt, aus einer Anleitung abgeschrieben, oder das Repository wurde umbenannt.
2. Das Repository ist nicht mit diesem Wiki verbunden. Dann trifft Repository nicht verbunden zu.
3. Die Einbindung wurde entfernt.

Prüfen

1. Öffnen Sie das Repository im Wiki und vergleichen Sie die dort ausgegebene Adresse zeichengenau mit der verwendeten.
2. Findet sich das Repository nicht in der Liste, ist es eine Frage der Sichtbarkeit und nicht der Adresse — weiter unter Ein Repository fehlt in der Liste.

Lösen: Die ausgegebene Adresse verwenden statt einer eigenen. Ist ein Repository in mehreren Sprachnamensräumen eingebunden, wird je Namensraum eine Adresse ausgegeben; für einen Clone genügt eine davon.

Eskalieren: Nur, wenn die ausgegebene Adresse zu dieser Meldung führt. Anfrage an die Administration, Art Administrative Änderung anfordern; nennen Sie die Adresse vollständig.

Sie sehen: not a git endpoint.

Umgebung: git clone mit einer von Hand gebauten Adresse.

Mögliche Ursache: Die Adresse trifft den Endpunkt, aber nicht auf einem der Wege, die ein Git-Client benutzt. Das entsteht regelmäßig dadurch, dass die Adresse aus der Browser-Adresszeile des Repository-Bildschirms kopiert wurde — die zeigt auf die Wiki-Seite, nicht auf den Git-Zugang. Beide beginnen gleich und enden verschieden.

Prüfen: Vergleichen Sie Ihre Adresse mit der im Abschnitt Dieses Repository beziehen ausgegebenen. Stimmt der vordere Teil und weicht der hintere ab, ist die Ursache gefunden.

Lösen: Die ausgegebene Adresse verwenden. Alternativ übergeben die Schaltflächen In VS Code öffnen und In JetBrains öffnen dieselbe Adresse unmittelbar an eine installierte Entwicklungsumgebung — damit entfällt das Kopieren.

Eskalieren: In aller Regel nicht nötig. Führt auch die ausgegebene Adresse dazu, gilt der vorige Abschnitt.

Sie sehen: push refused: gefolgt von einer Kennung — outside_own_prefix, no_prefix_for_user oder unreadable_command_list.

Umgebung: git push mit gültigem Token und mindestens der Stufe vorschlagen.

Mögliche Ursache: Die Kennung benennt sie eindeutig:

Wichtig für alle drei: Der gesamte Push wird abgelehnt, sobald ein einziges Ref außerhalb liegt — nicht nur das betreffende. Das ist Absicht: Andernfalls ließe sich ein zulässiger Branch mit einer unzulässigen Änderung bündeln und darauf hoffen, dass der Server das eine annimmt und das andere verwirft.

Prüfen

1. Lassen Sie sich anzeigen, was Sie tatsächlich schieben — ein Push überträgt oft mehr als den Branch, an den Sie gerade denken (etwa Tags).

git push --dry-run origin HEAD

1. Ihr eigenes Präfix lautet refs/heads/users/<Ihr Benutzername>/. Prüfen Sie, ob der Zielbranch darunter liegt.
2. Prüfen Sie im Abschnitt Dieses Repository beziehen, ob Sie überhaupt über die Stufe vorschlagen hinauskommen.

Lösen

1. outside_own_prefix: Schieben Sie unter Ihr eigenes Präfix. Innerhalb davon steht es Ihnen frei — anlegen, aktualisieren, überschreiben und löschen sind dort Ihre Sache, weshalb mehrere Vorschläge nebeneinander bestehen können:

git push origin HEAD:refs/heads/users/<Ihr Benutzername>/<Zweigname>

1. Schieben Sie ohne --tags und ohne --all, solange Sie nur die Stufe vorschlagen haben; beide nehmen Refs außerhalb Ihres Präfixes mit und lassen den ganzen Vorgang scheitern.
2. no_prefix_for_user: Nicht selbst lösbar — der Benutzername müsste geändert werden.
3. unreadable_command_list: Versuchen Sie es mit einem einzelnen, ausdrücklich benannten Ref erneut. Bleibt es dabei, ist es kein Bedienfehler.

Eskalieren

• Sie brauchen dauerhaft mehr als vorschlagen → Zugriff anfordern. Nennen Sie ausdrücklich, dass Sie auf gemeinsame Branches schreiben müssen und warum; das ist die Angabe, an der entschieden wird.
• no_prefix_for_user oder ein bleibendes unreadable_command_list → Anfrage an die Administration, Art Administrative Änderung anfordern. Nennen Sie den Benutzernamen und die vollständige Ausgabe des Git-Clients. Der Inhalt Ihrer Commits gehört nicht in die Anfrage.

Wie eine Änderung von Ihrem Präfix aus in das Projekt gelangt, steht unter Änderung einreichen.

Sie sehen: Die Token-Ablage ist nicht verfügbar., Das Token konnte nicht angelegt werden. oder Diese Aktion braucht zuerst einen für diese Sitzung nachgewiesenen zweiten Faktor, um ein Token anzulegen.

Umgebung: Token-Selbstverwaltung, angemeldete Sitzung.

Mögliche Ursache

1. Der letzte Fall ist kein Fehler. Für diese Installation ist für die Ausgabe von Token eine erhöhte Stufe eingestellt. Das betrifft nur das Erstellen, nicht die Benutzung eines bereits bestehenden Tokens.
2. Die Ablage ist nicht erreichbar. Dann kann kein Token entstehen; die Selbstverwaltung sagt das, statt beim Absenden zu scheitern.
3. Sie sind nicht angemeldet. Ohne Anmeldung ist die Selbstverwaltung nicht erreichbar.

Prüfen

1. Steht die Meldung über den zweiten Faktor, folgen Sie dem angebotenen Weg Jetzt nachweisen.
2. Erscheinen die beiden anderen Meldungen, versuchen Sie es nach kurzer Zeit noch einmal — eine vorübergehend nicht erreichbare Ablage erholt sich von selbst.

Lösen

1. Zweiter Faktor verlangt: dem Nachweis folgen. Ist für Ihr Konto keiner eingerichtet, richten Sie ihn zuerst ein; siehe Anmeldung, zweiter Faktor und Einladung.
2. Ablage nicht verfügbar: nicht selbst lösbar.

Eskalieren: Hält die Meldung über die Ablage an, Anfrage an die Administration, Art Administrative Änderung anfordern. Nennen Sie den Zeitpunkt und die genaue Meldung. Ein bestehendes Token, das noch funktioniert, bleibt davon unberührt — Sie sind also nicht zwingend blockiert.

• Störungen nachschlagen — die Meldung suchen
• Repository clonen — Adresse und Zugangsdaten
• Zugriffstoken erstellen — die Anleitung dazu
• Änderung einreichen — vom eigenen Präfix ins Projekt
• Projekte, Repositories und gesperrte Seiten — die Stufenleiter im Zusammenhang
• Anfrage an die Administration — der Eskalationsweg im Einzelnen