Im Admin, bereich benötige ich eine Funktion, Nutzer als Admin anschreiben zu können, dies soll den Kontakt mit mir vereinfachen und mir die möglichkeit geben, bei Verletzung der AGB´s oder des Datenschutzs rückfragen auf kurzen wege via chat zu starten.
Im Admin, bereich benötige ich eine Funktion, Nutzer als Admin anschreiben zu können, dies soll den Kontakt mit mir vereinfachen und mir die möglichkeit geben, bei Verletzung der AGB´s oder des Datenschutzs rückfragen auf kurzen wege via chat zu starten.
Datenschutz - Download, falls ein Nutzer seine Recht auf Auskunft ausüben möchte, würde ich dies gerne mittels Nutzer-Auswahl im Admin Menü einfach starten können.
Menü - Suchfunktion Nutzer
Auswahl der Daten -> Alle gesammelten Daten -> Zip Kompremiert -> OneFile via E-Mail an den Nutzer, E-Mail Adresse aus Clerk beziehen. -> Template mit einem Rechtssicheren Text in unserem Design, im Anhang die Datei
PlanB: falls das mit der E-Mail zu kompliziert ist, daten bereitstellung mit ablaufendem Link.
Erst prüfen dann bauen.
Datenschutz - Download, falls ein Nutzer seine Recht auf Auskunft ausüben möchte, würde ich dies gerne mittels Nutzer-Auswahl im Admin Menü einfach starten können.
Menü - Suchfunktion Nutzer
Auswahl der Daten -> Alle gesammelten Daten -> Zip Kompremiert -> OneFile via E-Mail an den Nutzer, E-Mail Adresse aus Clerk beziehen. -> Template mit einem Rechtssicheren Text in unserem Design, im Anhang die Datei
PlanB: falls das mit der E-Mail zu kompliziert ist, daten bereitstellung mit ablaufendem Link.
Erst prüfen dann bauen.
akutell werden, im Admin-Menü unter Users nur die user-id, anzahl der Tiere und deren Namen angezeigt, ist es möglich mehr informationen von clerk zu erhalten ?
akutell werden, im Admin-Menü unter Users nur die user-id, anzahl der Tiere und deren Namen angezeigt, ist es möglich mehr informationen von clerk zu erhalten ?
Mehr Clerk-Daten im Admin-Panel:admin.listUsers holt jetzt per Batch-Call E-Mail und Name aus Clerk und zeigt sie in /p/[secret]/users an.
Admin→Nutzer-Chat: Neue Mutation admin.startTeamConversation legt beim ersten Gebrauch ein System-Pet "PawFeed Team" unter ADMIN_OWNER_ID an und nutzt dafür das bestehende Conversation/Message-Modell (Pet-zu-Pet-DMs) weiter — kein neues UI auf Nutzerseite nötig. In der Users-Liste gibt's jetzt einen Chat-Button pro Nutzer.
Bekannte Einschränkung: Aktuell kann nur der Account mit ADMIN_OWNER_ID als Team schreiben (Ownership-Check verlangt exakte Übereinstimmung). Für weitere Moderatoren braucht das eine separate Erweiterung.
Recherche (Teil 3 — DSGVO-Art.-15-Export), wie gewünscht nur geprüft, nicht gebaut:
Rechtlicher Rahmen: Antwortfrist 1 Monat (verlängerbar auf 3 bei Komplexität), erste Kopie kostenlos, maschinenlesbares Format bei elektronischer Anfrage (Art. 15 DSGVO).
Was rein müsste: Owner-Stammdaten, alle Pets, Posts+Bilder, aktive Stories, Kommentare/Reaktionen/Reposts, eigene Nachrichten, Follows/Blocks, Health-Daten, Notifications, Reports, Ban-Historie, Consent-Zeitstempel, Clerk-Profildaten.
Harter Gap bei beiden vorgeschlagenen Wegen: Es gibt aktuell keine E-Mail-Versand-Infrastruktur im Projekt (kein Resend/SendGrid/Postmark/Nodemailer) und kein ZIP-Tooling — beides müsste neu eingeführt werden.
Plan A (E-Mail-Anhang): ZIP serverseitig bauen (Prisma-Daten + Clerk-Profil + Supabase-Storage-Downloads) und per Mail versenden. Risiko: bei vielen Posts/Videos dauert das Zusammenstellen zu lange für eine synchrone Anfrage; Video-Rohdaten liegen bei Mux und sind nicht ohne Weiteres exportierbar (müsste geprüft werden, ob die mp4_support-Rendition dafür nutzbar ist).
Plan B (ablaufender Link): Gleiche Datenaggregation, aber als zeitlich befristeter Download bereitgestellt — kann das bestehende Muster von /health-card/[token] wiederverwenden (tokenisierte, öffentliche Route ohne Auth, bereits produktiv im Code). Geringeres Architekturrisiko. Braucht trotzdem E-Mail, um den Link zuzustellen.
Einschätzung: Plan B auf Basis des Health-Card-Patterns ist der pragmatischere nächste Schritt, sobald eine E-Mail-Versand-Entscheidung getroffen ist (Anbieter, möglichst EU-Standort). Würde ich als eigenes, separates Issue vorschlagen statt in #6 mitzuführen.
**Umgesetzt (Teile 1+2, Commit `328e54c`, deployed):**
- **Mehr Clerk-Daten im Admin-Panel:** `admin.listUsers` holt jetzt per Batch-Call E-Mail und Name aus Clerk und zeigt sie in `/p/[secret]/users` an.
- **Admin→Nutzer-Chat:** Neue Mutation `admin.startTeamConversation` legt beim ersten Gebrauch ein System-Pet "PawFeed Team" unter `ADMIN_OWNER_ID` an und nutzt dafür das bestehende Conversation/Message-Modell (Pet-zu-Pet-DMs) weiter — kein neues UI auf Nutzerseite nötig. In der Users-Liste gibt's jetzt einen Chat-Button pro Nutzer.
- **Bekannte Einschränkung:** Aktuell kann nur der Account mit `ADMIN_OWNER_ID` als Team schreiben (Ownership-Check verlangt exakte Übereinstimmung). Für weitere Moderatoren braucht das eine separate Erweiterung.
**Recherche (Teil 3 — DSGVO-Art.-15-Export), wie gewünscht nur geprüft, nicht gebaut:**
Rechtlicher Rahmen: Antwortfrist 1 Monat (verlängerbar auf 3 bei Komplexität), erste Kopie kostenlos, maschinenlesbares Format bei elektronischer Anfrage (Art. 15 DSGVO).
Was rein müsste: Owner-Stammdaten, alle Pets, Posts+Bilder, aktive Stories, Kommentare/Reaktionen/Reposts, eigene Nachrichten, Follows/Blocks, Health-Daten, Notifications, Reports, Ban-Historie, Consent-Zeitstempel, Clerk-Profildaten.
**Harter Gap bei beiden vorgeschlagenen Wegen:** Es gibt aktuell **keine E-Mail-Versand-Infrastruktur** im Projekt (kein Resend/SendGrid/Postmark/Nodemailer) und **kein ZIP-Tooling** — beides müsste neu eingeführt werden.
- **Plan A (E-Mail-Anhang):** ZIP serverseitig bauen (Prisma-Daten + Clerk-Profil + Supabase-Storage-Downloads) und per Mail versenden. Risiko: bei vielen Posts/Videos dauert das Zusammenstellen zu lange für eine synchrone Anfrage; Video-Rohdaten liegen bei Mux und sind nicht ohne Weiteres exportierbar (müsste geprüft werden, ob die `mp4_support`-Rendition dafür nutzbar ist).
- **Plan B (ablaufender Link):** Gleiche Datenaggregation, aber als zeitlich befristeter Download bereitgestellt — kann das bestehende Muster von `/health-card/[token]` wiederverwenden (tokenisierte, öffentliche Route ohne Auth, bereits produktiv im Code). Geringeres Architekturrisiko. Braucht trotzdem E-Mail, um den Link zuzustellen.
**Einschätzung:** Plan B auf Basis des Health-Card-Patterns ist der pragmatischere nächste Schritt, sobald eine E-Mail-Versand-Entscheidung getroffen ist (Anbieter, möglichst EU-Standort). Würde ich als eigenes, separates Issue vorschlagen statt in #6 mitzuführen.
Zusammenfassung — alle drei Teile abgeschlossen und live verifiziert
1. Mehr Clerk-Daten im Admin-Panel
admin.listUsers holt jetzt per Batch-Call E-Mail und Name aus Clerk und zeigt sie in /p/[secret]/users an, statt nur der nackten User-ID.
2. Admin→Nutzer-Chat ("PawFeed Team")
Neue Mutation admin.startTeamConversation legt bei Bedarf ein System-Pet "PawFeed Team" unter ADMIN_OWNER_ID an und nutzt das bestehende Conversation/Message-Modell weiter — kein neues UI auf Nutzerseite nötig. Chat-Button pro Nutzer in der Users-Liste.
Bekannte Grenze: aktuell kann nur der ADMIN_OWNER_ID-Account als Team schreiben (Ownership-Check verlangt exakte Übereinstimmung). Für weitere Moderatoren wäre eine separate Erweiterung nötig.
3. DSGVO-Art.-15-Datenexport (Plan B)
Admin klickt "Export" bei einem Nutzer → Backend sammelt alle Daten (Pets, Posts, Stories, Kommentare, Reaktionen, Reposts, Follows/Blocks, Health-Daten, Nachrichten, Notifications, Reports, Ban-/Consent-Historie, Clerk-Profil) in ein JSON-Bundle → Upload in einen privaten Supabase-Storage-Bucket (getrennt vom öffentlichen Media-Bucket) → 7 Tage gültiger Signed-Link per E-Mail an die Clerk-Adresse. Protokolliert im ModerationLog.
Bewusst nicht enthalten (im Export selbst vermerkt): Werbeanzeigen-Interaktionen, ausgegebene Einladungscodes.
Bekannte Grenze: läuft synchron, kein automatisches Cleanup alter Export-Dateien im Storage.
Nebenbei aufgetreten: Mail-Versand komplett kaputt (nicht nur für den Export)
Beim ersten Testversand kam ein DMARC-Bounce zurück. Root-Cause-Analyse ergab: pawfeed.org hatte seit der Nameserver-Migration von Strato zu Cloudflare keinen SPF-Record und keine DKIM-Records mehr, obwohl eine strikte DMARC-Policy (p=reject) aktiv war — jede Mail von @pawfeed.org wurde dadurch von jedem DMARC-prüfenden Empfänger hart abgelehnt, nicht nur die Export-Mails. Behoben durch:
SPF-TXT-Record (v=spf1 redirect=_spf.strato.com) in Cloudflare ergänzt
Zwei DKIM-CNAME-Records (strato-dkim-0002/-0003._domainkey) ergänzt
Ein hängender Cloudflare-Edge-Cache-Zustand (TXT-Record am selben Namen wie ein bereits bestehender proxied Root-CNAME) musste per Löschen+Neuanlegen aufgelöst werden
Nach dem Fix: Testmail zugestellt und bestätigt angekommen.
End-to-End-Verifikation (heute durchgeführt)
Export für einen echten Account gebaut (3 Pets, alle Kategorien korrekt befüllt)
In privaten Bucket hochgeladen, Signed-URL erzeugt
Mail mit Link verschickt und Zustellung bestätigt
Link selbst abgerufen: HTTP 200, valides vollständiges JSON (16 KB)
Commits
328e54c — Clerk-Daten + Team-Chat
86ac5f4 — SMTP-Modul
f12dec0 — GDPR-Export-Feature
Alle Teile sind deployed und live auf pawfeed.org.
## Zusammenfassung — alle drei Teile abgeschlossen und live verifiziert
### 1. Mehr Clerk-Daten im Admin-Panel
`admin.listUsers` holt jetzt per Batch-Call E-Mail und Name aus Clerk und zeigt sie in `/p/[secret]/users` an, statt nur der nackten User-ID.
### 2. Admin→Nutzer-Chat ("PawFeed Team")
Neue Mutation `admin.startTeamConversation` legt bei Bedarf ein System-Pet "PawFeed Team" unter `ADMIN_OWNER_ID` an und nutzt das bestehende Conversation/Message-Modell weiter — kein neues UI auf Nutzerseite nötig. Chat-Button pro Nutzer in der Users-Liste.
- **Bekannte Grenze:** aktuell kann nur der `ADMIN_OWNER_ID`-Account als Team schreiben (Ownership-Check verlangt exakte Übereinstimmung). Für weitere Moderatoren wäre eine separate Erweiterung nötig.
### 3. DSGVO-Art.-15-Datenexport (Plan B)
Admin klickt "Export" bei einem Nutzer → Backend sammelt alle Daten (Pets, Posts, Stories, Kommentare, Reaktionen, Reposts, Follows/Blocks, Health-Daten, Nachrichten, Notifications, Reports, Ban-/Consent-Historie, Clerk-Profil) in ein JSON-Bundle → Upload in einen **privaten** Supabase-Storage-Bucket (getrennt vom öffentlichen Media-Bucket) → **7 Tage gültiger** Signed-Link per E-Mail an die Clerk-Adresse. Protokolliert im ModerationLog.
- **Bewusst nicht enthalten** (im Export selbst vermerkt): Werbeanzeigen-Interaktionen, ausgegebene Einladungscodes.
- **Bekannte Grenze:** läuft synchron, kein automatisches Cleanup alter Export-Dateien im Storage.
### Nebenbei aufgetreten: Mail-Versand komplett kaputt (nicht nur für den Export)
Beim ersten Testversand kam ein DMARC-Bounce zurück. Root-Cause-Analyse ergab: `pawfeed.org` hatte seit der Nameserver-Migration von Strato zu Cloudflare **keinen SPF-Record und keine DKIM-Records** mehr, obwohl eine strikte DMARC-Policy (`p=reject`) aktiv war — jede Mail von `@pawfeed.org` wurde dadurch von jedem DMARC-prüfenden Empfänger hart abgelehnt, nicht nur die Export-Mails. Behoben durch:
- SPF-TXT-Record (`v=spf1 redirect=_spf.strato.com`) in Cloudflare ergänzt
- Zwei DKIM-CNAME-Records (`strato-dkim-0002`/`-0003._domainkey`) ergänzt
- Ein hängender Cloudflare-Edge-Cache-Zustand (TXT-Record am selben Namen wie ein bereits bestehender proxied Root-CNAME) musste per Löschen+Neuanlegen aufgelöst werden
Nach dem Fix: Testmail zugestellt und bestätigt angekommen.
### End-to-End-Verifikation (heute durchgeführt)
1. Export für einen echten Account gebaut (3 Pets, alle Kategorien korrekt befüllt)
2. In privaten Bucket hochgeladen, Signed-URL erzeugt
3. Mail mit Link verschickt und Zustellung bestätigt
4. Link selbst abgerufen: HTTP 200, valides vollständiges JSON (16 KB)
### Commits
- `328e54c` — Clerk-Daten + Team-Chat
- `86ac5f4` — SMTP-Modul
- `f12dec0` — GDPR-Export-Feature
Alle Teile sind deployed und live auf pawfeed.org.
Den GDPR-Export optimieren,
aktuell wird der Link zum Export auf supabase übergeschrieben, können wir einen zwischenschritt hinzufügen. damit die leute die ihre auskunft holen diese von pawfeed.org erhalten statt von supabase
auf anfrage, pullt der server die daten legt die datei ab, erstellt einen token für das abholen der daten auf dem server (pawfeed.org)
prüfen ob das möglich ist ?
Den GDPR-Export optimieren,
aktuell wird der Link zum Export auf supabase übergeschrieben, können wir einen zwischenschritt hinzufügen. damit die leute die ihre auskunft holen diese von pawfeed.org erhalten statt von supabase
auf anfrage, pullt der server die daten legt die datei ab, erstellt einen token für das abholen der daten auf dem server (pawfeed.org)
prüfen ob das möglich ist ?
Follow-up umgesetzt: DSGVO-Export-Link läuft jetzt über pawfeed.org statt Supabase
Wie gewünscht (Variante 2 — eigenes DB-gestütztes Token-Modell statt Supabase-Signed-URL):
Neues DataExportToken-Modell (Prisma) mit token/storageKey/expiresAt
Neue öffentliche Route /api/gdpr-export/[token] (gleiches Muster wie /health-card/[token]) — validiert den Token, lädt die Datei serverseitig via Service-Role-Key von Supabase und streamt sie durch. Die Supabase-URL taucht nie im Browser/E-Mail-Link auf.
admin.exportUserData erzeugt jetzt einen DataExportToken statt einer Supabase-Signed-URL und mailt https://pawfeed.org/api/gdpr-export/{token}
Beim Live-Test direkt nach dem Deploy gefunden + gefixt: Die neue Route wurde zunächst von der Clerk-Middleware (src/proxy.ts) abgefangen und auf /sign-in umgeleitet, weil sie nicht im öffentlichen Route-Matcher stand — analog zu /health-card/(.*) ergänzt (Commit 8351382).
End-to-End verifiziert: echten Export über den Admin-Account gebaut, Mail mit dem neuen Link erhalten, Link direkt abgerufen (HTTP 200, valides JSON mit korrektem Content-Disposition: attachment-Header).
Commits: 5e2a11e (Feature), 8351382 (Proxy-Fix). Beide deployed und live auf pawfeed.org.
**Follow-up umgesetzt: DSGVO-Export-Link läuft jetzt über pawfeed.org statt Supabase**
Wie gewünscht (Variante 2 — eigenes DB-gestütztes Token-Modell statt Supabase-Signed-URL):
- Neues `DataExportToken`-Modell (Prisma) mit `token`/`storageKey`/`expiresAt`
- Neue öffentliche Route `/api/gdpr-export/[token]` (gleiches Muster wie `/health-card/[token]`) — validiert den Token, lädt die Datei serverseitig via Service-Role-Key von Supabase und streamt sie durch. Die Supabase-URL taucht nie im Browser/E-Mail-Link auf.
- `admin.exportUserData` erzeugt jetzt einen `DataExportToken` statt einer Supabase-Signed-URL und mailt `https://pawfeed.org/api/gdpr-export/{token}`
**Beim Live-Test direkt nach dem Deploy gefunden + gefixt:** Die neue Route wurde zunächst von der Clerk-Middleware (`src/proxy.ts`) abgefangen und auf `/sign-in` umgeleitet, weil sie nicht im öffentlichen Route-Matcher stand — analog zu `/health-card/(.*)` ergänzt (Commit `8351382`).
**End-to-End verifiziert:** echten Export über den Admin-Account gebaut, Mail mit dem neuen Link erhalten, Link direkt abgerufen (HTTP 200, valides JSON mit korrektem `Content-Disposition: attachment`-Header).
Commits: `5e2a11e` (Feature), `8351382` (Proxy-Fix). Beide deployed und live auf pawfeed.org.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Im Admin, bereich benötige ich eine Funktion, Nutzer als Admin anschreiben zu können, dies soll den Kontakt mit mir vereinfachen und mir die möglichkeit geben, bei Verletzung der AGB´s oder des Datenschutzs rückfragen auf kurzen wege via chat zu starten.
Datenschutz - Download, falls ein Nutzer seine Recht auf Auskunft ausüben möchte, würde ich dies gerne mittels Nutzer-Auswahl im Admin Menü einfach starten können.
Menü - Suchfunktion Nutzer
Auswahl der Daten -> Alle gesammelten Daten -> Zip Kompremiert -> OneFile via E-Mail an den Nutzer, E-Mail Adresse aus Clerk beziehen. -> Template mit einem Rechtssicheren Text in unserem Design, im Anhang die Datei
PlanB: falls das mit der E-Mail zu kompliziert ist, daten bereitstellung mit ablaufendem Link.
Erst prüfen dann bauen.
akutell werden, im Admin-Menü unter Users nur die user-id, anzahl der Tiere und deren Namen angezeigt, ist es möglich mehr informationen von clerk zu erhalten ?
Umgesetzt (Teile 1+2, Commit
328e54c, deployed):admin.listUsersholt jetzt per Batch-Call E-Mail und Name aus Clerk und zeigt sie in/p/[secret]/usersan.admin.startTeamConversationlegt beim ersten Gebrauch ein System-Pet "PawFeed Team" unterADMIN_OWNER_IDan und nutzt dafür das bestehende Conversation/Message-Modell (Pet-zu-Pet-DMs) weiter — kein neues UI auf Nutzerseite nötig. In der Users-Liste gibt's jetzt einen Chat-Button pro Nutzer.ADMIN_OWNER_IDals Team schreiben (Ownership-Check verlangt exakte Übereinstimmung). Für weitere Moderatoren braucht das eine separate Erweiterung.Recherche (Teil 3 — DSGVO-Art.-15-Export), wie gewünscht nur geprüft, nicht gebaut:
Rechtlicher Rahmen: Antwortfrist 1 Monat (verlängerbar auf 3 bei Komplexität), erste Kopie kostenlos, maschinenlesbares Format bei elektronischer Anfrage (Art. 15 DSGVO).
Was rein müsste: Owner-Stammdaten, alle Pets, Posts+Bilder, aktive Stories, Kommentare/Reaktionen/Reposts, eigene Nachrichten, Follows/Blocks, Health-Daten, Notifications, Reports, Ban-Historie, Consent-Zeitstempel, Clerk-Profildaten.
Harter Gap bei beiden vorgeschlagenen Wegen: Es gibt aktuell keine E-Mail-Versand-Infrastruktur im Projekt (kein Resend/SendGrid/Postmark/Nodemailer) und kein ZIP-Tooling — beides müsste neu eingeführt werden.
mp4_support-Rendition dafür nutzbar ist)./health-card/[token]wiederverwenden (tokenisierte, öffentliche Route ohne Auth, bereits produktiv im Code). Geringeres Architekturrisiko. Braucht trotzdem E-Mail, um den Link zuzustellen.Einschätzung: Plan B auf Basis des Health-Card-Patterns ist der pragmatischere nächste Schritt, sobald eine E-Mail-Versand-Entscheidung getroffen ist (Anbieter, möglichst EU-Standort). Würde ich als eigenes, separates Issue vorschlagen statt in #6 mitzuführen.
Zusammenfassung — alle drei Teile abgeschlossen und live verifiziert
1. Mehr Clerk-Daten im Admin-Panel
admin.listUsersholt jetzt per Batch-Call E-Mail und Name aus Clerk und zeigt sie in/p/[secret]/usersan, statt nur der nackten User-ID.2. Admin→Nutzer-Chat ("PawFeed Team")
Neue Mutation
admin.startTeamConversationlegt bei Bedarf ein System-Pet "PawFeed Team" unterADMIN_OWNER_IDan und nutzt das bestehende Conversation/Message-Modell weiter — kein neues UI auf Nutzerseite nötig. Chat-Button pro Nutzer in der Users-Liste.ADMIN_OWNER_ID-Account als Team schreiben (Ownership-Check verlangt exakte Übereinstimmung). Für weitere Moderatoren wäre eine separate Erweiterung nötig.3. DSGVO-Art.-15-Datenexport (Plan B)
Admin klickt "Export" bei einem Nutzer → Backend sammelt alle Daten (Pets, Posts, Stories, Kommentare, Reaktionen, Reposts, Follows/Blocks, Health-Daten, Nachrichten, Notifications, Reports, Ban-/Consent-Historie, Clerk-Profil) in ein JSON-Bundle → Upload in einen privaten Supabase-Storage-Bucket (getrennt vom öffentlichen Media-Bucket) → 7 Tage gültiger Signed-Link per E-Mail an die Clerk-Adresse. Protokolliert im ModerationLog.
Nebenbei aufgetreten: Mail-Versand komplett kaputt (nicht nur für den Export)
Beim ersten Testversand kam ein DMARC-Bounce zurück. Root-Cause-Analyse ergab:
pawfeed.orghatte seit der Nameserver-Migration von Strato zu Cloudflare keinen SPF-Record und keine DKIM-Records mehr, obwohl eine strikte DMARC-Policy (p=reject) aktiv war — jede Mail von@pawfeed.orgwurde dadurch von jedem DMARC-prüfenden Empfänger hart abgelehnt, nicht nur die Export-Mails. Behoben durch:v=spf1 redirect=_spf.strato.com) in Cloudflare ergänztstrato-dkim-0002/-0003._domainkey) ergänztNach dem Fix: Testmail zugestellt und bestätigt angekommen.
End-to-End-Verifikation (heute durchgeführt)
Commits
328e54c— Clerk-Daten + Team-Chat86ac5f4— SMTP-Modulf12dec0— GDPR-Export-FeatureAlle Teile sind deployed und live auf pawfeed.org.
Den GDPR-Export optimieren,
aktuell wird der Link zum Export auf supabase übergeschrieben, können wir einen zwischenschritt hinzufügen. damit die leute die ihre auskunft holen diese von pawfeed.org erhalten statt von supabase
auf anfrage, pullt der server die daten legt die datei ab, erstellt einen token für das abholen der daten auf dem server (pawfeed.org)
prüfen ob das möglich ist ?
Follow-up umgesetzt: DSGVO-Export-Link läuft jetzt über pawfeed.org statt Supabase
Wie gewünscht (Variante 2 — eigenes DB-gestütztes Token-Modell statt Supabase-Signed-URL):
DataExportToken-Modell (Prisma) mittoken/storageKey/expiresAt/api/gdpr-export/[token](gleiches Muster wie/health-card/[token]) — validiert den Token, lädt die Datei serverseitig via Service-Role-Key von Supabase und streamt sie durch. Die Supabase-URL taucht nie im Browser/E-Mail-Link auf.admin.exportUserDataerzeugt jetzt einenDataExportTokenstatt einer Supabase-Signed-URL und mailthttps://pawfeed.org/api/gdpr-export/{token}Beim Live-Test direkt nach dem Deploy gefunden + gefixt: Die neue Route wurde zunächst von der Clerk-Middleware (
src/proxy.ts) abgefangen und auf/sign-inumgeleitet, weil sie nicht im öffentlichen Route-Matcher stand — analog zu/health-card/(.*)ergänzt (Commit8351382).End-to-End verifiziert: echten Export über den Admin-Account gebaut, Mail mit dem neuen Link erhalten, Link direkt abgerufen (HTTP 200, valides JSON mit korrektem
Content-Disposition: attachment-Header).Commits:
5e2a11e(Feature),8351382(Proxy-Fix). Beide deployed und live auf pawfeed.org.