Files

elpatron 7c1866e6fc Initial commit: WebDAV-Adapter für Internxt Drive

- Browser-Token-Auth (INXT_TOKEN, INXT_MNEMONIC)
- Phase 1: PROPFIND (Verzeichnis auflisten)
- Drive API + Pfad-Resolver
- Dokumentation: Auth, Architektur, WSL

Made-with: Cursor

2026-02-28 10:54:29 +01:00

4.0 KiB

Raw Blame History

Internxt Auth-Analyse: Web vs CLI vs Rclone

Kernbefund: Client-Identifikation bestimmt Zugang

Der Backend-Server blockiert bestimmte Account-Tiers basierend auf der Client-Identifikation:

Client	clientName	Login-Methode	Endpoint	Status für eingeschränkte Tiers
drive-web	`drive-web`	`login()`	`/auth/login`	✅ Erlaubt
drive-desktop	`drive-desktop`	`login()`	`/auth/login`	✅ Erlaubt
internxt-cli	`internxt-cli`	`loginAccess()`	`/auth/login/access`	❌ Blockiert
rclone	(rclone-adapter)	loginAccess-ähnlich	`/auth/login/access`	❌ Blockiert

Quellen

drive-web (auth.service.ts)

const getAuthClient = (authType: 'web' | 'desktop') => {
  const AUTH_CLIENT = {
    web: SdkFactory.getNewApiInstance().createAuthClient(),      // clientName: "drive-web"
    desktop: SdkFactory.getNewApiInstance().createDesktopAuthClient(),  // clientName: "drive-desktop"
  };
  return AUTH_CLIENT[authType];
};

// Login mit authClient.login() - NICHT loginAccess()
return authClient.login(loginDetails, cryptoProvider)

createAuthClient(): clientName: packageJson.name = "drive-web"
createDesktopAuthClient(): clientName: "drive-desktop"
Methode: login() (nicht loginAccess)

CLI (auth.service.ts)

const authClient = SdkManager.instance.getAuth();
const data = await authClient.loginAccess(loginDetails, CryptoService.cryptoProvider);

getAppDetails(): clientName: packageJson.clientName = "internxt-cli" (aus package.json)
Methode: loginAccess() (nicht login)

SDK Factory (drive-web)

private static getAppDetails(): AppDetails {
  return {
    clientName: packageJson.name,   // "drive-web"
    clientVersion: packageJson.version,
    customHeaders,
  };
}

private static getDesktopAppDetails(): AppDetails {
  return {
    clientName: 'drive-desktop',
    clientVersion: packageJson.version,
  };
}

Lösung für WebDAV-Wrapper

Strategie: Den Auth-Client so konfigurieren, dass er sich als drive-web ausgibt und login() statt loginAccess() verwendet.

@internxt/sdk mit Auth.client(apiUrl, appDetails, apiSecurity) verwenden
appDetails setzen: { clientName: "drive-web", clientVersion: "1.0" }
login() aufrufen (nicht loginAccess())
CryptoProvider wie in drive-web implementieren (passToHash, decryptText, getKeys, parseAndDecryptUserKeys)

Abhängigkeiten für WebDAV-Wrapper

@internxt/sdk (Version 1.13.x oder kompatibel – drive-web nutzt 1.13.2)
@internxt/lib (für aes, Crypto)
Crypto-Logik aus drive-web: app/crypto/services/keys.service, app/crypto/services/utils
Keys-Format: ECC + Kyber (post-quantum)

Aktueller Status (Stand: Analyse)

CRYPTO_SECRET: Korrekt (Salt-Decryption OK mit 6KYQBP847D4ATSFA)
loginWithoutKeys: Liefert weiterhin "Wrong login credentials" – möglicherweise lehnt das Backend diesen Flow für bestimmte Account-Typen (z.B. mailbox.org-Partner) ab
login() mit Keys: Kyber-WASM schlägt unter Windows fehl (@dashlane/pqc-kem-kyber512-node)

Nächste Schritte

Ansatz B testen: Browser-basierter Token-Extrakt – im Web einloggen, Session-Token aus localStorage/DevTools lesen, im Wrapper verwenden
login() unter Linux: Kyber-Paket könnte unter Linux funktionieren
Internxt-Support: Nachfragen, ob Partner-Accounts (mailbox.org) andere Auth-Flows nutzen

CRYPTO_SECRET und API-URL

Aus internxt/cli .env.template:

DRIVE_API_URL: https://gateway.internxt.com/drive
APP_CRYPTO_SECRET: 6KYQBP847D4ATSFA

Der PoC nutzt diese Werte als Fallback.

4.0 KiB Raw Blame History Unescape Escape