Credential Management

Wo der Anthropic-API-Key und der GitHub-Token leben, und wie du sie setzt, ohne sie in deiner Shell-History zu hinterlassen.

← Zurück zur Übersicht · 🇬🇧 English · ← Step-Description Localization · FAQ →

Wofür das ist

Zwei Framework-Features rufen in deinem Auftrag einen externen Dienst auf und brauchen dafür eine Zugangsdaten:

Beide werden auf dieselbe Art gespeichert: im nativen Passwort-Tresor deines Betriebssystems, nie in einer .env-Datei, nie in deiner Shell-History. Diese Seite behandelt den Speicher-Mechanismus und den npx cc-testframework config-Befehl, mit dem du ihn verwaltest. ANTHROPIC_API_KEY als reine Umgebungs-Variable — der ursprüngliche Setup-Pfad — funktioniert weiterhin unverändert; alles Folgende ist eine zusätzliche, bequemere Option obendrauf.

💡 Nutzt du nur Self-Healing Vision? Dafür gibt es auch einen leichtgewichtigeren, provider-agnostischen Pfad, der den OS-Credential-Store gar nicht braucht — die Umgebungs-Variable AI_API_KEY, oder ein mit npx cc-testframework set-ai-key per-Maschine persistierter Key. Siehe Self-Healing Locators — Kosten und BYOK für die vollständige Priority-Chain. Das OS-Credential-Store-Setup auf dieser Seite bleibt daneben vollständig unterstützt und ist weiterhin das, was der Custom-Step-Authoring-Agent (npx cc-testframework author) nutzt.

Wo Zugangsdaten gespeichert werden

Plattform Speicher
Windows Windows Credential Manager
macOS macOS Keychain
Linux Secret Service (über den Keyring-Daemon deiner Desktop-Session, z.B. GNOME Keyring oder KWallet)

Jeder Eintrag wird unter dem Service-Namen cc-testframework gespeichert, gebunden an den OS-Benutzer-Account, unter dem das Framework läuft. Nichts wird irgendwo hin übertragen außer direkt an den Dienst, zu dem die Zugangsdaten gehören (Anthropic für den Vision-Key, GitHub für den Token) — das Framework selbst sieht, proxyt oder loggt den rohen Wert nie.

💡 Kein Desktop-Keyring verfügbar (z.B. ein headless Linux-CI-Runner)? Lesen und Auflisten von Zugangsdaten degradieren dann sauber zu “nichts gefunden”, statt einen Fehler zu werfen — das Framework fällt auf die nächste Stufe in der Priority-Chain weiter unten zurück (Abschnitt “Priority-Chain für die automatische Auflösung”). Schreiben degradiert zu einer Fehlermeldung, die dich auf --value/--stdin oder den einfachen Env-Var-Fallback verweist.

Der First-Run-Prompt

Beim ersten Mal, wenn das Framework eine Zugangsdaten braucht, die noch nirgends konfiguriert ist, und es in einem interaktiven Terminal läuft, fragt es einmalig danach:

No anthropic-api-key found.
Enter your anthropic-api-key:
Save to system keychain for future runs? [Y/n]

Der eingegebene Wert wird nie im Terminal angezeigt. Antwortest du mit Y (oder drückst einfach Enter — das ist der Default), wird der Wert über den oben beschriebenen OS-Credential-Store gespeichert, sodass jeder spätere Lauf ihn automatisch findet. Antwortest du mit n, wird der Wert trotzdem für den aktuellen Lauf genutzt, nur nicht persistiert.

Dieser Prompt erscheint ausschließlich in einem interaktiven Terminal. In einem nicht-interaktiven Kontext (ein CI-Job, ein Skript, das Eingaben von woanders her pipet) fragt das Framework nie nach — ein Prompt dort würde für immer auf eine Eingabe warten, die nie kommt. Es meldet stattdessen die fehlende Zugangsdaten und beendet sich; siehe den Abschnitt “Nicht-interaktives Setup” weiter unten für die unterstützte Alternative.

Zugangsdaten über den config-Befehl verwalten 

npx cc-testframework config set <name> [options]      # Zugangsdaten speichern
npx cc-testframework config get <name> [options]       # maskierte Zugangsdaten + Status anzeigen
npx cc-testframework config delete <name> [options]    # gespeicherte Zugangsdaten entfernen
npx cc-testframework config list [options]             # alles aktuell Gespeicherte auflisten
npx cc-testframework config types                       # bekannte Credential-Typen auflisten

npx cc-testframework config set anthropic-api-key
# Enter your anthropic-api-key: ****************
# Save to system keychain for future runs? [Y/n] y
# ✔ Stored 'anthropic-api-key' in system keychain (global)

npx cc-testframework config get anthropic-api-key
# sk-ant-A****...**xyz  (global, expires: 2026-08-01T00:00:00Z)

npx cc-testframework config list
# Stored credentials:
#   - anthropic-api-key    (global)
#   - github-token         (project: github.com/your-org/your-repo)

config get/config list geben nie den rohen Wert aus — nur eine maskierte Form (erste 7 + letzte 3 Zeichen, oder **** bei kürzeren Werten).

Optionen

Option Gilt für Effekt
--value <string> set Wert inline übergeben — sichtbar in Shell-History und Prozess-Liste, daher nur für lokales, kurzlebiges Setup geeignet.
--stdin set Liest den Wert stattdessen von stdin — siehe den Abschnitt “Nicht-interaktives Setup” weiter unten.
(kein Flag) set Interaktiver Prompt mit verstecktem Input — der Default beim Laufen in einem Terminal.
--expires-at <ISO-8601> set Ablauf-Zeitstempel, für einen OAuth-Access-Token, der einen hat. Weglassen bei einem langlebigen Personal Access Token oder API-Key.
--source <name> set Informativer Tag, z.B. pat, oauth-device, oauth-app — wird von get/list zurückgegeben, rein zur eigenen Buchführung.
--project <id> set / get / delete Expliziter Projekt-Id, überschreibt die Git-Remote-Auto-Erkennung — siehe Projekt-Scoping.
--global set / get / delete Erzwingt globalen Scope für einen normalerweise projekt-gescopten Credential-Typ.
--format text\|json get / list text (Default, human-readable) oder json (für Skripte und anderes Tooling, das die Ausgabe programmatisch konsumiert).
--help, -h alle Gibt die Nutzung aus.

Exit-Codes

Code Bedeutung
0 Erfolg.
1 Nicht gefunden, oder der OS-Credential-Store ist nicht verfügbar/fehlgeschlagen.
2 User-Fehler — ungültige Argumente, unbekannter Credential-Typ, sich gegenseitig ausschließende Flags, oder ein nicht-interaktives set ohne --value/--stdin.
4 Credential-bezogener Fehler — der gespeicherte Wert ist abgelaufen, hat ein ungültiges Format, oder der Eintrag im Speicher ist korrupt. config get gibt bei einer abgelaufenen Zugangsdaten ebenfalls 4 zurück (gibt vorher trotzdem den maskierten Wert und Status aus).

Bekannte Credential-Typen

Name Default-Scope Beschreibung
anthropic-api-key Global (ein Key pro OS-Benutzer) Anthropic-API-Key für Vision-basiertes Self-Healing und Custom-Step-Authoring (BYOK).
github-token Projekt (pro Repository) Ein Token für Tooling, das sich bei GitHub authentifiziert — siehe die akzeptierten Formate unten.

Führe jederzeit npx cc-testframework config types aus, um diese Liste aus deiner installierten Version auszugeben.

Akzeptierte GitHub-Token-Formate

Prefix Token-Art Akzeptiert
ghp_ Personal Access Token (classic) Ja
github_pat_ Fein-granularer Personal Access Token Ja
ghs_ GitHub-App Server-to-Server-Token Ja
gho_ OAuth-App / OAuth-Device-Flow-Access-Token Ja
ghu_ GitHub-App User-to-Server-Token Ja
ghr_ Refresh-Token Nein

Ein Refresh-Token (ghr_) ist selbst nie nutzbar, um die GitHub-API aufzurufen oder in ein Repository zu pushen — er kann nur gegen einen neuen Access-Token eingetauscht werden. Einen solchen unter github-token zu speichern würde beim ersten Gebrauch stillschweigend fehlschlagen, daher weist config set ihn von vornherein mit einem Format-Fehler zurück.

Projekt-Scoping

github-token ist standardmäßig projekt-gescoped — ein fein-granularer PAT oder OAuth-Token, der auf ein einzelnes Repository beschränkt ist, ist üblich, und verschiedene Projekte brauchen oft verschiedene Tokens. Die Projekt-Id wird automatisch aus git config --get remote.origin.url in deinem aktuellen Arbeitsverzeichnis erkannt, normalisiert zu <host>/<owner>/<repo> (sodass die SSH-, HTTPS- und git://-Formen desselben Remotes alle zum selben gespeicherten Eintrag auflösen).

# Erkennt das Projekt automatisch aus dem Origin-Remote des aktuellen Repos
npx cc-testframework config set github-token --stdin

# Expliziter Projekt-Id (z.B. beim Ausführen von außerhalb des Ziel-Repos)
npx cc-testframework config set github-token --project github.com/your-org/your-repo --stdin

# Ein Token für jedes Projekt (ein Solo-Entwickler mit einem einzigen PAT überall)
npx cc-testframework config set github-token --global --stdin

Beim Lesen (get/list, und die interne Auflösung des Frameworks selbst) wird zuerst der projekt-gescopte Eintrag für das aktuelle Repository geprüft, mit Fallback auf einen global-gescopten Eintrag, falls kein projekt-spezifischer existiert. anthropic-api-key ist immer global — er akzeptiert kein --project.

Priority-Chain für die automatische Auflösung

Tools, die auf dem Framework aufbauen (wie die Authoring-Agent-CLI), lösen eine Zugangsdaten automatisch auf, indem sie der Reihe nach Folgendes prüfen und beim ersten Treffer stoppen:

  1. Ein expliziter Wert, direkt ans Tool übergeben (z.B. --anthropic-api-key <value> an der author-CLI).
  2. Die entsprechende Umgebungs-Variable (ANTHROPIC_API_KEY / GITHUB_TOKEN).
  3. Der OS-Credential-Store, projekt-gescopter Eintrag.
  4. Der OS-Credential-Store, global-gescopter Eintrag.
  5. Der interaktive First-Run-Prompt — nur in einem Terminal.

Das bedeutet, den Credential-Store zu nutzen ist vollständig optional: ein bestehendes export ANTHROPIC_API_KEY=...-Setup funktioniert unverändert weiter und hat Vorrang vor allem, was via config set gespeichert wurde.

Nicht-interaktives Setup (für CI und automatisiertes Tooling)

Ein Skript oder ein externes Tool, das das Framework ohne einen Menschen an der Tastatur ansteuert, sollte --stdin statt --value nutzen — so taucht der Wert nie in einer Prozess-Liste oder Shell-History auf:

echo -n "$ANTHROPIC_API_KEY" | npx cc-testframework config set anthropic-api-key --stdin

Dasselbe Muster funktioniert für einen Token, der über einen externen Authentifizierungs-Flow bezogen wurde (zum Beispiel ein Tool, das einen Nutzer durch GitHubs OAuth-Device-Flow führt und den resultierenden Access-Token anschließend ans Framework übergibt):

echo -n "$FRESH_ACCESS_TOKEN" | npx cc-testframework config set github-token \
  --stdin --source oauth-device --expires-at 2026-07-15T18:00:00Z

--expires-at und --source sind beide optionale Metadaten — setze sie, wann immer die Zugangsdaten einen bekannten Ablauf haben, damit das Framework rechtzeitig warnen und bei tatsächlichem Ablauf vorhersehbar fehlschlagen kann (siehe unten), statt einen kryptischen Authentifizierungs-Fehler vom entfernten Dienst durchzureichen.

💡 Das Framework erneuert einen Token nie selbst. Es liest und speichert nur, was ihm übergeben wird — das Erneuern eines abgelaufenen OAuth-Tokens ist Aufgabe dessen, was ihn ursprünglich bezogen hat. Läuft ein Token ab, besorg dir über den Flow deines Providers einen neuen und setze ihn erneut mit config set ... --stdin.

Ablauf und Gnadenfrist

Eine mit --expires-at gespeicherte Zugangsdaten trägt diesen Zeitstempel durch jede Leseoperation. Drei Dinge können passieren, wenn das Framework sie auflöst:

Situation Verhalten
Mehr als 5 Minuten bis zum Ablauf Normal genutzt, keine Warnung.
Innerhalb von 5 Minuten vor Ablauf Für diesen Lauf noch genutzt, plus eine Warnung, dass eine Erneuerung ansteht.
Bereits abgelaufen Als unbrauchbar behandelt — das Framework fällt durch, als wäre nichts gespeichert, und jeder Aufrufer, der darauf angewiesen ist, schlägt schnell mit einem Credential-bezogenen Fehler fehl (siehe die Exit-Codes des Authoring-Agenten — Code 4), statt eine zum Scheitern verurteilte Anfrage an den entfernten Dienst zu schicken.

Eine ohne --expires-at gespeicherte Zugangsdaten (ein langlebiger Personal Access Token oder API-Key, der übliche Fall) löst nichts davon aus — sie gilt auf unbestimmte Zeit als gültig.

Progress-Events (für Tooling, das auf der CLI aufbaut)

Alles, was npx cc-testframework author programmatisch ansteuert (via onProgress / onCredentialProgress an runAuthorCli/runAuthorTestRunner — siehe API-Referenz), erhält eine von sechs Credential-bezogenen Event-Phasen, statt die Terminal-Ausgabe parsen zu müssen:

Phase Bedeutung
credential-expired Der exp-Zeitstempel einer gespeicherten Zugangsdaten liegt in der Vergangenheit.
credential-expiring-soon Eine gespeicherte Zugangsdaten läuft innerhalb von 5 Minuten ab, ist für diesen Lauf aber noch nutzbar.
credential-missing Nirgends in der Priority-Chain konnte etwas aufgelöst werden.
credential-invalid Ein Wert wurde eingegeben (interaktiv oder über die API), der die Format-Prüfung des Credential-Typs nicht besteht.
interactive-prompt-required Der First-Run-Prompt würde normalerweise erscheinen, aber der aktuelle Kontext ist kein interaktives Terminal.
interactive-prompt-shown Der First-Run-Prompt wird gerade angezeigt.

Test-Account-Zugangsdaten verwalten

Dieser Abschnitt behandelt ein zweites, unabhängiges Credential-System: Test-Account-Zugangsdaten — die Nutzername/Passwort-Paare, mit denen sich deine TestCases in der zu testenden Anwendung anmelden, verwaltet über Core.PasswordManager und gespeichert in einer verschlüsselten PasswordManager.json-Datei. Es nutzt ein anderes Speicher-Design als die oben beschriebenen Framework-Credentials, aufgebaut auf einem Zwei-Schichten-Modell statt allein auf dem OS-Credential-Store.

💡 Voraussetzung: die Befehle unten setzen voraus, dass das Framework bereits innerhalb von pm/ über die license-brokered Proxy-Registry installiert ist — siehe Quickstart — Schritt 3: Authentifizierung bootstrappen und Projekt scaffolden, falls du CC_LICENSE_KEY noch nicht eingerichtet hast.

Das Zwei-Schichten-Modell verstehen

  • Das Passwort-Manager-Secret — ein einzelner AES-256-Verschlüsselungs-Key für dein Projekt. Er lebt im OS-Keychain jedes Entwicklers (demselben nativen Speicher, der oben beschrieben ist) und wird nie ins Repository geschrieben.
  • PasswordManager.json — die verschlüsselte Datei selbst. Sie liegt innerhalb von pm/ (pm/2_Apps/1_Global/ per Default) und wird via git verfolgt wie jede andere Datei, synct also ganz normal zum Team.
  • Die Projekt-Id — der Keychain-Eintrag ist namentlich gescoped, abgeleitet aus dem name-Feld in pm/package.json (Fallback: der Name des pm/-Ordners selbst, falls das Feld fehlt). Deshalb ist das Secret “für Projekt X”, und deshalb ist das name-Feld in pm/package.json Voraussetzung, damit das zuverlässig funktioniert.

Zur Laufzeit kombiniert das Framework beide: es sucht das Passwort-Manager-Secret für deine Maschine, und nutzt es dann, um den einzelnen benötigten Eintrag aus PasswordManager.json zu entschlüsseln. Die Auflösung prüft der Reihe nach: die Umgebungs-Variable CC_PASSWORD_MANAGER_SECRET, dann deinen OS-Keychain, dann (veraltet) Core.Constant.passwordSecretKey in GlobalConfig.ts — siehe Vom veralteten passwordSecretKey migrieren weiter unten, falls du das noch nutzt. Löst nichts auf, sagt dir die Kommandozeile genau, was als Nächstes zu tun ist.

Das erste Team-Mitglied onboarden

Der erste Entwickler eines Projekts generiert ein frisches Secret und speichert es im eigenen Keychain:

npx cc-testframework password init
# Existing team-secret? (paste hex) or generate new? (Enter):
# ✔ Password-manager secret initialized for project 'your-app' (stored in OS keychain).
#   Generated secret (share with your team via 1Password/Slack-DM, etc.): 3f9a...c1e0

Übergib --secret <hex> oder --stdin statt des interaktiven Prompts für ein skriptbares Setup. init verweigert das Überschreiben eines bestehenden Keychain-Eintrags, außer du fügst --force hinzu.

Weitere Team-Mitglieder onboarden

Jeder weitere Entwickler braucht dasselbe Secret — das erste Team-Mitglied teilt es out-of-band (ein 1Password-Eintrag, eine Slack-DM, ein Secrets-Manager — alles außer es in git zu committen oder an eine E-Mail zu hängen, die in einem Postfach landet). Jeder Kollege führt dann aus:

npx cc-testframework password init --stdin
# das geteilte Hex-Secret einfügen, Enter drücken

Ab diesem Zeitpunkt kann diese Maschine jeden bestehenden Eintrag in PasswordManager.json entschlüsseln und neue hinzufügen — kein weiterer Onboarding-Schritt pro Zugangsdaten nötig.

💡 Warum out-of-band? PasswordManager.json reist ganz normal mit deinem Repo (Clone, Pull, PR-Review). Das Secret bewusst nicht — wer nur Repo-Zugriff hat, jetzt oder aus einem geleakten Backup, bekommt nie den Key, der zum Entschlüsseln nötig ist.

Geteilt mit anderen Tools, die deine Test-Suite steuern

PasswordManager.json und seine Auflösungs-Kette sind nicht exklusiv für diese CLI — jedes andere Tool, das TestCases für dasselbe Projekt verwaltet oder ausführt (zum Beispiel eine begleitende Test-Management-UI, die TestCases im Auftrag eines Testers scaffoldet), liest und schreibt exakt dieselbe Datei, über exakt dieselbe Priority-Chain. Es gibt keinen separaten Credential-Tresor, den ein CLI-getriebener Entwickler und ein UI-getriebener Tester im selben Team synchron halten müssten — der OS-Keychain übernimmt für den CLI-Nutzer dieselbe Rolle, die der eigene Speicher des begleitenden Tools für dessen Nutzer übernimmt, und beide Seiten lösen dasselbe entschlüsselte Passwort für denselben Nutzernamen auf.

Eine Zugangsdaten anlegen 

npx cc-testframework password set --username admin --stdin
# Passwort einfügen, Enter drücken
# ✔ Stored credentials for 'admin'

Nutze immer --stdin (oder den interaktiven Prompt, ganz ohne Flag) statt --value — ein Klartext-Test-Account-Passwort auf der Kommandozeile landet für die Dauer des Prozesses in deiner Shell-History und in ps aux. password get --username admin liest es zurück (default maskiert, --raw zeigt es an), password list zeigt nur gespeicherte Nutzernamen, und password delete --username admin entfernt einen Eintrag.

Das Setup prüfen (password status)

password status zeigt, was tatsächlich konfiguriert ist, ohne je ein Secret oder einen Passwort-Wert auszugeben — nützlich, wenn password get/password set mit einem “does not decrypt”-Fehler fehlschlägt und du wissen musst warum:

npx cc-testframework password status
# Password-manager status:
#   project:        your-app
#   secret source:  keychain
#   password file:  /path/to/your-app/pm/2_Apps/1_Global/PasswordManager.json
#   entries:        3
#   decryptable:    true

Es gibt die aufgelöste Projekt-Id aus (siehe Das Zwei-Schichten-Modell verstehen oben), aus welcher der drei Stufen das Secret tatsächlich kam (env-var / keychain / das veraltete Feld), den PasswordManager.json-Pfad, die Anzahl der Einträge, und ob sich aktuell jeder Eintrag mit dem aufgelösten Secret entschlüsseln lässt. --format json liefert dieselben Felder als JSON fürs Skripting.

Das Secret rotieren (password rotate)

Verschlüsselt jeden Eintrag in PasswordManager.json mit einem brandneuen Secret neu und gibt dieses neue Secret einmalig aus, damit du es genauso wie beim Onboarding out-of-band teilen kannst. Nutze es nach einem vermuteten Leak (ein altes Secret über einen unsicheren Kanal geteilt, eine Maschine, die seither ausgemustert wurde) oder als periodische Hygiene-Maßnahme:

npx cc-testframework password rotate
# ✔ Rotated the password-manager secret and re-encrypted 3 entries.
#   New secret (share with your team via 1Password/Slack-DM, etc.): 7c1f...9ae2

Nach dem Rotieren führt jedes weitere Team-Mitglied npx cc-testframework password init --stdin --force mit dem neuen Secret erneut aus — der alte Keychain-Eintrag entschlüsselt die Datei nicht mehr, genau wie beim ersten Onboarding.

Eine Zugangsdaten in deinem Test auslesen

Lies das gespeicherte Passwort über den mitgelieferten TS_GetPassword-Step aus, statt in deinem TestCase direkt einen Core-Service aufzurufen — er nimmt nur seinen einen Business-Parameter entgegen, keine führende refId:

const pw = await Project.Utilities.TS_GetPassword('admin');
await Project.<DeineApp>.TS_Main_Passwordfield_Fill(pageLogName, sectionName, 'Password', pw);

TS_GetPassword liefert das entschlüsselte Passwort zurück und loggt nur den Nutzernamen in den Report — der Passwort-Wert selbst wird nirgends in der Ausgabe geschrieben. Die tiefer liegende Core.PasswordManager.getPassword(...)-API, die dieser Step wrappt, existiert weiterhin für fortgeschrittene/programmatische Nutzung außerhalb eines TestSteps (siehe API-Referenz — Sektion 13); innerhalb eines TestCase ist TS_GetPassword der empfohlene Weg. Siehe Migration auf v0.22.0 weiter unten, falls du von einer älteren Call-Shape aktualisierst.

CI einrichten

CI-Runner haben keinen OS-Keychain, setze das Secret dort also stattdessen über eine Umgebungs-Variable — CC_PASSWORD_MANAGER_SECRET hat Vorrang vor Keychain und dem veralteten Feld, und wird bei jedem Lauf gelesen, ganz ohne password init-Schritt:

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Install dependencies
        working-directory: pm
        env:
          CC_LICENSE_KEY: $
        run: npm ci
      - name: Run tests
        working-directory: pm
        env:
          CC_PASSWORD_MANAGER_SECRET: $
        run: npx playwright test

npm ci liest pm/package-lock.json und pm/.npmrc — Letztere trägt bereits die in Quickstart — Schritt 3 gescaffoldete ${CC_LICENSE_KEY}-Referenz, das gleichnamige Secret bei deinem CI-Provider zu setzen genügt also. Speichere beide Werte im eigenen Secrets-Store deines CI-Providers (GitHub-Actions-Secrets, Vault, Azure Key Vault, …) — nie als reine Workflow-Datei-Variable. PasswordManager.json selbst ist bereits ins Repo eingecheckt, es ist also kein zusätzlicher Schritt nötig, um es auf den Runner zu bekommen.

Das Secret für einen einzelnen Lauf überschreiben

Um ein anderes Secret auszuprobieren, ohne den Keychain anzufassen — zum Beispiel um das Secret eines Kollegen zu testen, bevor du dich mit password init --force festlegst — übergib es inline für einen einzelnen Aufruf, aus pm/ heraus:

CC_PASSWORD_MANAGER_SECRET=<value> npx playwright test 3_Cases/TC_Login.spec.ts

Das nutzt Stufe 1 der Priority-Chain von oben (Das Zwei-Schichten-Modell verstehen) für genau diesen einen Lauf — es hat Vorrang vor Keychain und dem veralteten Feld, und nichts wird irgendwo persistiert, sobald der Prozess beendet ist.

Migration auf v0.22.0

Breaking Change. Vor v0.22.0 nahm TS_GetPassword eine führende refId entgegen (TS_GetPassword(refId, username)), passend zur Call-Shape eines TS_Main_*-Steps gegen deine eigene App. Seit v0.22.0 entfällt dieses Argument — dieselbe “kein Screen-Element, kein Referenz-Screenshot, nichts zu binden”-Begründung aus den Migrations-Hinweisen der OS-App und der FTP-App gilt auch hier.

// vorher (≤ 0.21.0)
const pw = await Project.Utilities.TS_GetPassword('', 'admin');

// nachher (0.22.0)
const pw = await Project.Utilities.TS_GetPassword('admin');

Aktualisiere jede TS_GetPassword-Aufrufstelle in deinem Projekt, indem du das führende Leerstring-Argument entfernst.

Vom veralteten passwordSecretKey migrieren

  1. Finde den aktuellen Wert von Core.Constant.passwordSecretKey in GlobalConfig.ts deines Projekts.
  2. Verschiebe ihn in den Keychain: npx cc-testframework password init --secret <der-bestehende-key>.
  3. Lösche die Zeile Core.Constant.passwordSecretKey = '...' aus GlobalConfig.ts und committe.

PasswordManager.json muss sich nicht ändern — das Verschlüsselungs-Format ist in beiden Fällen identisch, nur woher der Key kommt, ändert sich. Bis du migrierst, funktioniert das veraltete Feld weiter, mit einer einmaligen Deprecation-Warnung pro Lauf, die auf diesen Abschnitt verweist.

Bedrohungsmodell

Dieses Design schützt vor einem geleakten oder kurzzeitig öffentlichen Repository, einer Backup- oder Mirror-Exfiltration, und jedem, der git log/Blame-History durchsucht — in jedem dieser Fälle ist nur das verschlüsselte JSON exponiert, nie der Key, der zum Lesen nötig ist. Es schützt nicht vor einer bereits kompromittierten Entwickler-Maschine (ein Angreifer, der deinen Keychain lesen kann, entschlüsselt genau das, was du auch kannst), jemandem, der beim Onboarding das Secret über die Schulter mitliest, oder einem Leak von CC_PASSWORD_MANAGER_SECRET aus dem eigenen Secrets-Store deines CI-Providers — dessen Absicherung liegt in der Verantwortung deines CI-Providers, genau wie bei jedem anderen CI-Secret.

Wo es weitergeht

📧 Fragen? Kontakt: jens.szelag@itsbusiness.ch

itsbusiness AG · Bern · Schweiz