stooze Handbuch

Darstellung

Universal Links bereitstellen ​

Technische Bereitstellungsnotiz, Stand 2026-09-12. App und Website sind vorbereitet; Veröffentlichung, signierter iOS-Build und Geräteabnahme stehen aus.

Die iOS-App verwendet applinks:stooze.de. Die Zuordnung liegt in docs/public/.well-known/apple-app-site-association und wird in den statischen Build übernommen. App-ID gemäß Projektkonfiguration: 789M7BSBD7.de.stooze.app. Vor der Geräteabnahme mit dem application-identifier des signierten Archivs abgleichen. Nur /einladung und /passwort-zuruecksetzen sind freigegeben. Widgets und Watch benötigen diese Berechtigung nicht. Keine Backend-Änderung ist erforderlich.

Website veröffentlichen ​

Den Inhalt von docs/.vitepress/dist/ inklusive verstecktem Verzeichnis .well-known veröffentlichen. Danach muss https://stooze.de/.well-known/apple-app-site-association ohne Anmeldung oder Weiterleitung HTTP 200 mit dem JSON-Inhalt liefern. Content-Type: application/json. Die Datei darf weder in einen HTML-Fallback fallen noch durch eine allgemeine Sperre für Punktdateien blockiert werden. Auf Nginx beispielsweise im bestehenden Website-Serverblock ergänzen, falls die aktuelle Konfiguration es benötigt:

nginx
location = /.well-known/apple-app-site-association {
    default_type application/json;
    try_files $uri =404;
}

Kein www-Alias oder API-Hostname ist freigegeben. Bestehende Einladungsmails müssen https://stooze.de/einladung#token=… verwenden.

Datenschutz und Bedienung ​

Die Seite liest ausschließlich den Fragment-Token im Browser und erzeugt daraus fest stooze://einladung#token=…. Keine Speicherung, Analyse, Backend-Abfrage oder Weitergabe an TestFlight. Ungültige oder doppelte Token erzeugen keinen Öffnen-Link. Die native App und das Backend prüfen die Einladung vor dem tatsächlichen Beitritt.

Es gibt keine automatische Weiterleitung zum Store und keine Erkennung, ob die App installiert ist. Die expliziten Buttons verhindern Redirect-Schleifen. Die Installation übernimmt kein Einladungstoken; anschließend denselben Link erneut antippen. Browserentscheidungen für die Website respektiert iOS; der App-Button und das manuelle Einfügen bleiben deshalb als Alternativen erhalten.

Prüfen ​

node --experimental-strip-types --test tests/invitation-link.test.mjs prüft Tokenverarbeitung und Zuordnungsumfang, npm run docs:build den Website-Build. Nach Veröffentlichung zuerst die AASA-Antwort prüfen, dann den neuen TestFlight- Build installieren. In Mail einen echten Einladungslink antippen: kalte und warme App, gültige/abgelaufene Einladung, angemeldet/abgemeldet und ohne installierte App. Apple cached Zuordnungsdateien; ein Website-Upload allein aktualisiert nicht sofort jede bereits installierte App. Das Provisioning-Profil muss Associated Domains enthalten; bei automatischem Signing wird es beim nächsten signierten Build erneuert.

Apple: Associated Domains

Passwort-AutoFill ​

Die Zuordnungsdatei enthält zusätzlich webcredentials.apps mit ausschließlich 789M7BSBD7.de.stooze.app. Die Haupt-App deklariert webcredentials:stooze.de. Diese gegenseitige Zuordnung unterstützt iOS-Passwortvorschläge zur Registrierung und Anmeldung. Website-Datei und neuer signierter App-Build müssen beide bereitgestellt werden. Apples Zuordnungs-Cache und der gewählte Passwortmanager beeinflussen die Geräteprüfung. Die Datei enthält keine Zugangsdaten.

Native Passwort-Wiederherstellung (2026-09-13) ​

AASA umfasst zusätzlich ausschließlich /passwort-zuruecksetzen. Der Backend- Ursprung ios erzeugt diesen HTTPS-Link mit Token im Fragment. Die App öffnet nativ die Passwortmaske. Web/Admin nutzt einen eigenen konfigurierten Reset-Pfad, der in AASA nicht enthalten sein darf. Kein User-Agent-Routing.

Die statische Reset-Seite bietet nur Hinweise zum Öffnen in der App. Sie verarbeitet kein Token, ruft keine Reset-API auf und verweist nicht zur Admin-Konsole. Vor Verfügbarkeit müssen AASA/Seite, Backend und neuer signierter App-Build bereitgestellt werden. Apples Association-Cache und echte Mail-Links auf einem Gerät müssen danach geprüft werden. In dieser Aufgabe erfolgt kein Deployment.

Android verarbeitet nativ https://stooze.de/einladung und https://app.stooze.de/join-team. Die öffentliche Zuordnung ist vorbereitet, aber noch nicht veröffentlicht: Die Play-App samt App Signing ist laut Bestätigung noch nicht eingerichtet. Beide öffentlichen /.well-known/assetlinks.json-Adressen lieferten bei der lesenden Prüfung HTTP 404. Der manuelle Einstieg „Team beitreten“ funktioniert davon unabhängig.

Für die Freigabe wird das bestätigte SHA-256-App-Signaturzertifikat von de.stooze.app benötigt. Keine öffentliche Zuordnung der Debug-App. Androids assetlinks.json wird separat neben der bestehenden Apple-Zuordnung bereitgestellt; die Website-Trennung muss beide .well-known-Dateien und /einladung erhalten. Die zweite Android-Zuordnung auf app.stooze.de gehört zur Web-Anwendung. Die Signaturdatei ist kein Installationslink und enthält keine Einladungstokens.

Der führende technische Vertrag liegt im Android-Repository unter docs/app-links.md: überschreibgeschützter Generator, lesender HTTPS-Prüfer, Abgleich mit Play und abschließende Geräteprüfung. Ein erfolgreiches lokales Intent- oder USB-Szenario bestätigt noch keine öffentliche Domainverifikation. Kein Play-Store-Ziel wird vor dessen Bestätigung eingetragen.

Veröffentlichung der Play-Zuordnung (13.10.2026) ​

Die Play Console für de.stooze.app liefert unter App-Signatur die bestätigte Digital-Asset-Links-Konfiguration. Diese ist jetzt in den Quellen unter documentation/docs/public/.well-known/assetlinks.json und web-app/public/.well-known/assetlinks.json gespeichert. Produktiv liefern beide Domains die identische Datei direkt über Nginx aus; führende Betriebsquelle ist /opt/stooze/operations/public/assetlinks.json, öffentliche Ablage /var/www/stooze/app-links/assetlinks.json. Betrieb und Rücknahme stehen im Serverrepository unter docs/hosting.md. Frühere Hinweise auf fehlende Play- Einrichtung beziehungsweise unveröffentlichte Zuordnung sind damit überholt.

Beide HTTPS-Endpunkte liefern 200, application/json und exakt die bestätigte Release-Zuordnung ohne Redirect. Sieben Generator-/Manifest-/Prüfertests bestanden. Apple-Zuordnung bytegleich erhalten; iOS-Entitlement und nativer Resetpfad mit Android-Manifest abgeglichen. Keine Änderungen an nativer Darstellung, Navigation, Fokus, Kontodaten oder Realtime; die Ergänzung betrifft die OS-Domainverifikation. Die physische Android-Prüfung mit dem intern über Play installierten Build und einem Mail-Link bleibt offen. Der bisherige Browser-Hinweis bleibt unverändert.