Update subproject commit to indicate a dirty state

This commit is contained in:
2026-01-18 01:45:07 +01:00
parent e73ddd52ad
commit 99413db4f4
24 changed files with 1001 additions and 2229 deletions

View File

@@ -1,53 +0,0 @@
# Appwrite API Key Setup
## API Key erstellen
1. **Appwrite Console oeffnen**: https://cloud.appwrite.io
2. **Projekt auswaehlen**: Waehle dein Projekt (ID: `696b82bb0036d2e547ad`)
3. **Settings > API Keys** navigieren
4. **"Create API Key"** klicken
5. **Konfiguration**:
- **Name**: `EShip Extension Key` (oder beliebiger Name)
- **Scopes**:
- `users.read` - Benutzer lesen
- `users.write` - Benutzer erstellen/bearbeiten
- `sessions.write` - Sessions erstellen
- Optional: Weitere Scopes je nach Bedarf
- **Expiration**: Optional (leer lassen fuer unbegrenzt)
6. **"Create"** klicken
7. **API Key kopieren** - WICHTIG: Der Key wird nur einmal angezeigt!
## API Key in Extension konfigurieren
1. Oeffne `Extension/config.js`
2. Fuege den API Key hinzu:
```javascript
var APPWRITE_CONFIG = {
endpoint: 'https://cloud.appwrite.io/v1',
projectId: '696b82bb0036d2e547ad',
apiKey: 'DEIN_API_KEY_HIER' // Hier den kopierten Key einfuegen
};
```
3. Extension neu laden in `chrome://extensions`
## Sicherheit
- **NIEMALS** den API Key in Git committen
- Der API Key sollte nur in der Extension verwendet werden
- Bei Verlust: Alten Key loeschen und neuen erstellen
- Verwende unterschiedliche Keys fuer Development und Production
## Alternative: Environment-basierte Konfiguration
Fuer Production kannst du den API Key auch ueber Chrome Storage setzen:
1. In der Extension: `chrome.storage.local.set({ apiKey: 'DEIN_KEY' })`
2. Im Service Worker: Key aus Storage laden
## Troubleshooting
- **"Invalid API Key"**: Pruefe, ob der Key korrekt kopiert wurde (keine Leerzeichen)
- **"Insufficient permissions"**: Pruefe die Scopes des API Keys
- **"Key expired"**: Erstelle einen neuen API Key

View File

@@ -1,58 +0,0 @@
# API Server Setup
## Problem
Chrome Extensions haben unterschiedliche IDs bei jeder Installation. Appwrite erfordert Platform-Registrierung, was nicht praktikabel ist.
## Lösung
Ein Express API-Server fungiert als Proxy zwischen Extension und Appwrite. Der Server verwendet den API Key (server-seitig, keine Platform-Registrierung nötig) und erstellt Sessions fuer die Extension.
## Installation
1. Dependencies installieren:
```bash
cd Server
npm install
```
2. API Server starten:
```bash
npm run dev:api
```
Der Server laeuft auf `http://localhost:3001`
## Beide Server gleichzeitig starten
```bash
npm run dev:all
```
Startet sowohl Vite (Port 5173) als auch API Server (Port 3001).
## Umgebungsvariablen (optional)
Erstelle eine `.env` Datei im `Server/` Ordner:
```
APPWRITE_ENDPOINT=https://appwrite.webklar.com/v1
APPWRITE_PROJECT_ID=696b82bb0036d2e547ad
APPWRITE_API_KEY=dein_api_key_hier
```
Falls nicht gesetzt, werden die Default-Werte aus `api-server.js` verwendet.
## API Endpoints
- `POST /api/extension/login` - Login mit Email/Password
- `GET /api/extension/auth` - Prueft Auth-Status
- `POST /api/extension/logout` - Logout
- `GET /api/health` - Health Check
## Vorteile
- Keine Platform-Registrierung in Appwrite noetig
- Funktioniert fuer alle Extension-Installationen
- API Key bleibt sicher auf dem Server
- Einfache Skalierung

View File

@@ -0,0 +1,174 @@
# Users Collection Setup & Permissions
Diese Anleitung erklärt, wie du die `users` Collection in Appwrite einrichtest und die richtigen Permissions setzt.
## Problem: 401 Unauthorized
Wenn du beim Erstellen eines User-Dokuments einen **401 Unauthorized** Fehler bekommst, bedeutet das, dass die Permissions der Collection nicht richtig gesetzt sind.
## Lösung: Collection erstellen und Permissions setzen
### Schritt 1: Collection-ID ermitteln oder erstellen
#### Option A: Collection bereits vorhanden
Prüfe, ob die Collection bereits existiert:
```bash
cd Server
appwrite login
appwrite databases list-collections --database-id eship-db
```
Suche nach einer Collection mit dem Namen "users" oder einer ID, die du verwenden möchtest.
#### Option B: Collection erstellen
Falls die Collection nicht existiert, erstelle sie:
```bash
appwrite databases create-collection \
--database-id eship-db \
--collection-id users \
--name "Users"
```
**Wichtig**: Notiere dir die `$id` der erstellten Collection. Falls die Collection-ID nicht "users" ist, musst du sie in der `.env` Datei setzen:
```
VITE_APPWRITE_USERS_COLLECTION_ID=<deine-collection-id>
```
### Schritt 2: Attribute hinzufügen
Die Collection braucht ein `user_name` Feld (String):
```bash
appwrite databases create-string-attribute \
--database-id eship-db \
--collection-id users \
--key user_name \
--size 255 \
--required true
```
**Wichtig**: Warte, bis das Attribute erstellt wurde (Status: "available"). Das kann einige Sekunden dauern.
### Schritt 3: Permissions setzen
Das ist der wichtigste Schritt! Die Collection muss erlauben, dass:
- Authentifizierte User Dokumente lesen können
- Authentifizierte User Dokumente erstellen können (für ihr eigenes Dokument)
#### Über die Appwrite-Konsole (empfohlen)
1. Öffne die Appwrite-Konsole: `https://appwrite.webklar.com`
2. Gehe zu: **Databases****eship-db****users** Collection
3. Klicke auf **Settings****Permissions**
4. Füge folgende Permissions hinzu:
**Create Permission:**
- Role: `users`
- Erlaube: **create**
**Read Permission:**
- Role: `users`
- Erlaube: **read**
**Update Permission (optional, falls du Updates brauchst):**
- Role: `users`
- Erlaube: **update**
**Delete Permission (optional):**
- Role: `users`
- Erlaube: **delete**
#### Über die CLI
```bash
# Create Permission
appwrite databases create-collection-create-rule \
--database-id eship-db \
--collection-id users \
--role users
# Read Permission
appwrite databases create-collection-read-rule \
--database-id eship-db \
--collection-id users \
--role users
# Optional: Update Permission
appwrite databases create-collection-update-rule \
--database-id eship-db \
--collection-id users \
--role users
# Optional: Delete Permission
appwrite databases create-collection-delete-rule \
--database-id eship-db \
--collection-id users \
--role users
```
**Hinweis**: Die CLI-Befehle können je nach Appwrite-Version variieren. Wenn sie nicht funktionieren, verwende die Web-Konsole.
### Schritt 4: Document-ID-Permissions
Da wir die Auth-User-ID als Document-ID verwenden, muss Appwrite erlauben, dass User ihre eigene Document-ID verwenden können.
In der Appwrite-Konsole:
1. Gehe zu: **Databases****eship-db****users****Settings**
2. Stelle sicher, dass **"Allow users to specify their own document IDs"** aktiviert ist
- Oder setze: **"Document ID Generation"** auf **"User provided"**
### Schritt 5: Überprüfung
Nach dem Setup sollte:
- ✅ Ein eingeloggter User Dokumente lesen können
- ✅ Ein eingeloggter User sein eigenes Dokument erstellen können (mit seiner Auth-User-ID als Document-ID)
## Häufige Probleme
### Problem: "Collection not found"
**Lösung**: Prüfe, ob die Collection-ID korrekt ist:
```bash
appwrite databases list-collections --database-id eship-db
```
Stelle sicher, dass `VITE_APPWRITE_USERS_COLLECTION_ID` in der `.env` die richtige ID enthält.
### Problem: "Attribute not found"
**Lösung**: Prüfe, ob das `user_name` Attribute existiert:
```bash
appwrite databases list-attributes \
--database-id eship-db \
--collection-id users
```
### Problem: "Permission denied"
**Lösung**: Stelle sicher, dass die Permissions für die Rolle `users` gesetzt sind. In der Appwrite-Konsole:
- Gehe zu **Settings****Permissions**
- Prüfe, ob `create` und `read` für `users` aktiviert sind
## Alternative: Restriktivere Permissions (sicherer)
Falls du sicherer sein möchtest, dass User nur ihr eigenes Dokument lesen/erstellen können:
1. In der Appwrite-Konsole: Gehe zu **Settings****Permissions**
2. Verwende **Custom Permissions** mit Filtern:
- Read: `$userId = request.auth.userId`
- Create: `$userId = request.auth.userId`
- Update: `$userId = request.auth.userId`
Dies stellt sicher, dass User nur Zugriff auf ihr eigenes Dokument haben.
## Nächste Schritte
Nach dem Setup:
1. Lade die Web-App neu
2. Logge dich ein
3. Du solltest den Welcome-Screen sehen
4. Beim Klick auf "Jetzt starten" sollte das User-Dokument erstellt werden (kein 401-Fehler mehr)