# Aktivvo CLI

Kleines Python-CLI, das die Aktivvo-Website nicht per Browser steuert, sondern dieselben Padam-API-Calls wie das Frontend verwendet.

## Wichtige Grenze

Die POST-Endpoints sind auf `start.aktivvo.padam.io` durch CrowdSec / reCAPTCHA geschützt. Das Tool umgeht diese Hürde nicht.

Praktisch heißt das:

1. Im Browser die Aktivvo-Seite öffnen.
2. Falls das CrowdSec / reCAPTCHA erscheint, dort freischalten.
3. Falls Buchungen gemacht werden sollen, normal im Browser einloggen.
4. Entweder aus den Browser-Devtools den vollständigen `Cookie`-Header für `https://start.aktivvo.padam.io` kopieren oder `login-browser` / `import-cookies` nutzen.
5. Diesen Cookie-Header dem CLI übergeben.

Wenn der Cookie-Header `authz_pdm=...` enthält, zieht das CLI den Token automatisch daraus und setzt `Authorization: Token ...`. Bei OpenID-Sessions nutzt es `Bearer`.

Stand 16. März 2026 ist für diese Deployment-URL kein belastbarer reiner CLI-Username/Password-Login nachweisbar: `POST /api/v1.7/signin` liefert auch mit mobilen Padam-Headern nur `500`, und OpenID ist in der Web-Konfiguration leer. Der praktikable Login für die CLI ist daher ein browsergestützter Session-Import.

## Installation

```bash
python3 -m venv .venv
source .venv/bin/activate
pip install -e .
```

## Basisnutzung

Cookie einmal in eine Umgebungsvariable legen:

```bash
export AKTIVVO_COOKIE_HEADER='crowdsec=...; authz_pdm=...'
```

Oder direkt aus Chrome importieren:

```bash
eval "$(aktivvo import-cookies --browser chrome --format env)"
```

Oder den Login direkt aus der CLI anstoßen, Browser öffnen lassen und auf die Session warten:

```bash
eval "$(aktivvo login-browser --browser chrome --format env)"
```

Falls schon eine gültige Session im gewählten Browser-Profil liegt, gibt `login-browser` sie sofort zurück. Für einen echten Neu-Login:

```bash
eval "$(aktivvo login-browser --browser chrome --wait-for-new-token --format env)"
```

Falls macOS den Keychain-Zugriff blockiert oder hängen bleibt, kann das Safe-Storage-Passwort auch explizit gesetzt werden:

```bash
AKTIVVO_SAFE_STORAGE_PASSWORD='...' aktivvo import-cookies --browser chrome --format env
```

Nodes für ein Gebiet anzeigen:

```bash
aktivvo search-nodes --territory holzwinkel --limit 20
```

Aktuellen Benutzer prüfen:

```bash
aktivvo current-customer
```

Suche auf Basis zweier Node-IDs:

```bash
aktivvo search \
  --territory holzwinkel \
  --from-id 1055 \
  --to-id 1056 \
  --datetime '2026-03-17T10:00:00+01:00'
```

Search-Response analysieren:

```bash
aktivvo inspect-search search-response.json
```

Direkt aus einer gespeicherten Search-Response buchen:

```bash
aktivvo book-from-search-response \
  search-response.json \
  --territory holzwinkel \
  --payment-method onboard \
  --customer-id 111 \
  --indications 'Bitte an der Bushaltestelle warten'
```

Buchung finalisieren:

```bash
aktivvo book \
  --territory holzwinkel \
  --reservation-history-id 12345 \
  --customer-proposition-id 67890 \
  --payment-method onboard \
  --customer-id 111 \
  --indications 'Bitte an der Bushaltestelle warten'
```

## Reverse-Engineerte Payloads

Die wichtigsten Payloads sind direkt aus dem Frontend-Bundle abgeleitet:

- Suche: `POST /api/v1.7/get-rides-multinode`
- Finale Buchung: `POST /api/v1.7/validate-booking`
- Proposition-Validierung: `POST /api/searchrequests/{searchRequestId}/propositions/{propositionId}/validate/`
- Aktueller Nutzer: `GET /api/customers/current/` mit `Accept: application/json; version=2.0`
- Cookie-Import: lokales Chromium-Cookie-DB-Parsing auf macOS mit Keychain-Entschlüsselung

Die CLI ist absichtlich roh gehalten und gibt JSON aus, damit man Responses zuerst inspizieren und danach gezielt weitere Calls bauen kann.
