Registrieren, Login und Speichern von Nutzern

[BlazingTwist]

Da inzwischen diverse Stellen aufkommen, an denen wir Bedarf haben, einen Nutzer zu referenzieren, soll ein System implementiert werden, mit dem sich Nutzer Registrieren und Anmelden können.

Das wird Nachfolgen auf diese Features haben:

• Dynamischere Themeauswahl im Frontend #21 Theme-Auswahl
• Multiplayer Chat implementieren #28 Multiplayer-Chat

Das integrieren der Nutzerverwaltung in diese Featues ist bestandteil dieses Issues.

---

Checkliste für die Basisimplementierung:

• dx
  • REST Schnittstellen definieren
• Backend
  • Datenbankanbindung
  • REST endpoint für die Nutzer-Registration
  • REST endpoint für den Nutzer-Login (? Details noch unklar)
• Frontend
  • Fenster für das Registrieren
  • Fenster für den Login

[martinmarth]

Wäre https://clerk.com/docs als AuthProvider eine Möglichkeit?
Dann hätten wir Fancy Sign-Ins.

So lange wir von denen die User-Id abgreifen können, müsste das doch für uns ausreichen oder? @BlazingTwist
Heißt, im Frontend findet das Sign-In/Up statt und das übermittelt dem Backend dann die UserId

[BlazingTwist]

Wirkt ein bisschen overkill, aber könnten wir machen.
Wenn ich das recht verstehe, brauchen wir dann aber 2 Secrets:

• CLERK_SECRET_KEY im Frontend
• und das Bearer Token im Backend

Was mir dabei unbequem aufschlägt: wie kriegen wir die secrets automatisch und sicher an die jeweiligen Entwickler?
Secrets mit Github an Github Actions zu "veröffentlichen" ist kein Problem, aber du brauchst die Secrets geauso, wenn du als Entwickler den Server lokal laufen lassen willst. (Sonst bräuchten wir 2 Nutzerverwaltungen: dev und prod)

Noch problematischer wird's, wenn unsere Kursleiter den Server starten wollen - diese sollten offensichtlich keinen Zugriff auf die Secrets haben.

Oder überseh ich was offensichtliches?

[martinmarth]

Ja das stimmt, also automatisch wird das schwierig.
Wir könnten die Secrets in die OVGU-Cloud packen und mit PW sichern.

Wenn wir den nächsten Milestone aushändigen, packen wir das PW für die Cloud mit in die Mail.
So hätten wir eine Art mini Keystore 😅.

Aber ja, das wäre schon irgendwie Overkill.
Andererseits ist eine selbstgeschriebene Auth-Lösung aber auch etwas Aufwand.

[BlazingTwist]

Registrierung und Login mit Benutzernamen und Passwort ist kein Problem.
Generierung von TOTP (2FA) habe ich mir auch schonmal angesehen, könnte ich auch einbauen. (Wäre aber für eine Schach Website genauso overkill)
Ob man unbedingt passwortlose Registrierung mit Google/etc braucht. shrug

Speichern der Konfiguration müssten wir sowieso selbst machen.

Sonst was, was ich vergesse?

[martinmarth]

Naja rein theoretisch bräuchten wir nur Benutzername und Passwort, ja.

Aber beeindruckender wäre halt ein ganzes Auth-System mit Profilbild, Passwort vergessen, Löschung und Co.
Gleichzeitig kommt Clerk mit einem Profile-Dashboard, das heißt der Frontend Code müsste auch nicht entwickelt werden 😆
Aber für den Kurs wäre es auf jeden Fall Overkill, stimme ich zu.
Sollte man das Spiel jedoch mal veröffentlichen wollen, ists mit Clerk cooler meiner Meinung nach 😅

[BlazingTwist]

Wenn du das unbedingt implementieren möchtest, habe ich Zuhause nen Server laufen, wo wir das dann als Docker Container aufspielen können.
Dann bräuchten wir aber einen Gast-Login, dass man als Entwickler auch testen kann, ohne das auf den Server laden zu müssen.
(Denke Gast-Login wäre auch allgemein sinnvoll, nicht jeder will sich gleich registrieren müssen)