Login-Modus

Der Login-Modus ist die erste und wichtigste Entscheidung beim Auth-Setup. Er legt App-weit fest, wann sich Nutzer in deiner App anmelden müssen — und wirkt sich auf alle Module aus, die einen eingeloggten Nutzer brauchen (Shop-Checkout, Kommentare, Buchungen, eigenes Profil, Forum-Posts, …).

Die zwei Modi

Optional (empfohlen)

Die App startet ohne Login. Nutzer sehen Inhalte als Gast und werden erst dann zum Login gebeten, wenn sie etwas tun möchten, das einen Account braucht.

Login beim Start

Jeder Nutzer muss sich direkt beim App-Start anmelden, bevor er die App überhaupt sieht. Splash → Login → App.

---

Optional anmelden (Standard)

Im Modus „Optional” (intern: onDemand) verhält sich die App so:

Situation	Verhalten
App-Start	Splash → Home. Kein Login-Screen.
Inhalt lesen (Feed, Shop, Kurse, Forum)	Funktioniert als Gast.
Aktion ausführen, die einen Account braucht	App zeigt den Login-Screen, danach springt sie zurück zur ursprünglichen Aktion.
Nutzer schließt den Login wieder	Nichts passiert. Nutzer kann weiter als Gast unterwegs sein.

Beispiele für „braucht einen Account”:

• Shop-Checkout abschließen (wenn „Gast-Checkout” aus ist)
• Kommentar / Forum-Post / Bewertung schreiben
• Kurs einschreiben oder Lektion als „abgeschlossen” markieren
• Eigenes Profil öffnen oder bearbeiten
• Gutschein einlösen (wenn „Login für Gutscheine” an ist)
• Folgen / Liken / Bookmarken

Für 95 % der Apps die richtige Wahl

„Optional” ist der Default. Du verlierst keine Nutzer am ersten Bildschirm, gewinnst aber trotzdem volle Account-Funktionen sobald sie sie brauchen.

---

Login beim Start

Im Modus „Login beim Start” (intern: forceOnStart) verhält sich die App so:

Situation	Verhalten
App-Start	Splash → Login-Screen. Home ist erst nach Login erreichbar.
Nicht eingeloggter Nutzer	Sieht gar nichts außer Login und Registrierung.
Nach erfolgreichem Login	Home wird angezeigt, normaler App-Betrieb beginnt.
Bedarfs-Logins in Modulen	Entfallen — der Nutzer ist immer eingeloggt.

Wann sinnvoll?

• Interne Mitarbeiter-Apps ohne öffentliche Inhalte
• B2B-Apps, die nur mit Vertrag/Kunden-Konto funktionieren
• Apps mit ausschließlich personalisiertem Inhalt
• Apps, die keinen Gast-Zugang zeigen dürfen (rechtlich / vertraglich)

Höhere Einstiegs-Hürde

Verlangst du Login direkt beim ersten Öffnen, springen viele Nutzer wieder ab, bevor sie die App überhaupt gesehen haben. Im Zweifel: Optional wählen.

---

Wo wird der Modus gesetzt?

Nur im Setup-Wizard

Der Login-Modus wird ausschließlich im Setup-Schritt „Login-Modus” gesetzt. Im laufenden Editor des Auth-Moduls gibt es bewusst keinen Toggle dafür, weil sich das Verhalten quer durch alle Module zieht — ein Wechsel im laufenden Betrieb würde existierende Module in einen inkonsistenten Zustand bringen.

Wenn du den Modus später ändern willst:

1. Edit Mode öffnen → Module & Features
2. Bei Authentifizierung auf Deaktivieren tippen
3. Modul erneut aktivieren
4. Im ersten Wizard-Schritt den gewünschten Modus wählen

Daten bleiben erhalten

Beim Deaktivieren/Reaktivieren des Auth-Moduls bleiben Nutzer-Accounts, Auth-Methoden-Auswahl und OAuth-Konfiguration erhalten. Es wird wirklich nur der Modus neu gesetzt.

---

Modul-spezifische Login-Settings

Zusätzlich zum globalen Modus können einzelne Module selbst entscheiden, ob sie Login einfordern. Beispiele:

Modul	Setting	Default
Shop	loginRequiredForCheckout / enableGuestCheckout	Gast erlaubt
Coupons	loginRequiredForReferral	Aus
Forum	(immer Login-pflichtig für Posts)	Hart
Profile	(immer Login-pflichtig zum Bearbeiten)	Hart

Logik im Zusammenspiel:

• Login beim Start aktiv → diese Settings sind faktisch egal, Nutzer ist eh eingeloggt
• Optional aktiv → Modul prüft sein eigenes Setting; ist es aus, läuft die Aktion als Gast; ist es an, fordert das Modul Login an

Default „Gast erlaubt”

Neue modul-spezifische Login-Settings starten aus. So entscheidest du bewusst pro Funktion, ob ein Login wirklich nötig ist — statt Nutzer unnötig zum Login zu zwingen.

---

Was Module technisch tun

Hintergrund für Entwickler / fortgeschrittene Nutzer:

• Module rufen nicht direkt /login auf, sondern den zentralen Service AuthGateService.requireLogin(returnRoute, reasonKey).
• Im „Login beim Start”-Modus ist dieser Aufruf ein No-Op, weil der Nutzer schon eingeloggt ist — kein Pop-up, keine Doppel-Navigation.
• Im „Optional”-Modus öffnet requireLogin den Login-Screen, optional mit einer Hinweis-Snackbar („Bitte melde dich an, um zu kommentieren”), und springt nach erfolgreichem Login zurück zur ursprünglichen Route.
• Module dürfen nicht anhand von „ist firebase_auth als Modul aktiv?” entscheiden, ob ein Nutzer eingeloggt ist — das wäre falsch. Das Auth-Modul aktiv zu haben heißt nur, dass Login möglich ist, nicht dass der Nutzer eingeloggt ist.

---

Häufige Fragen

Kann ich den Modus während eines laufenden Tests wechseln?

Ja, im App Builder problemlos — Modul deaktivieren, reaktivieren, neuen Modus wählen. Mock-Daten bleiben erhalten.

Was passiert mit dem Modus beim Veröffentlichen?

Der Modus wird mit veröffentlicht. Deine Live-App verhält sich genau so wie im App Builder konfiguriert.

Kann ich den Modus pro Plattform unterschiedlich setzen?

Nein. Der Modus gilt App-weit für iOS, Android und Web identisch.

Was, wenn ich Anonym-Login aktiv habe?

Anonym-Login ergänzt den „Optional”-Modus elegant: Nutzer kann sich „leise” anonym anmelden, ohne Daten preiszugeben, und sein anonymes Konto später in ein echtes Konto umwandeln. Bei „Login beim Start” spielt Anonym kaum eine Rolle — wenn jemand sich ohnehin am Anfang anmelden soll, dann meist mit echtem Konto.

---

Nächste Schritte

Auth-Methoden auswählen E-Mail, Google, Apple, Anonym & mehr

Design-Vorlage wählen Login-Design aus 8 Vorlagen auswählen

Zurück zur Übersicht Auth-Modul Übersicht