Compare commits

...

4 commits

Author SHA1 Message Date
87066919d4 chore: Add docs for coinflip
All checks were successful
CI / eslint (pull_request) Has been skipped
CI / Backend Tests (pull_request) Has been skipped
CI / oxlint (pull_request) Has been skipped
CI / Docker frontend validation (pull_request) Has been skipped
CI / test-build (pull_request) Has been skipped
Label PRs based on size / Check PR size (pull_request) Successful in 13s
CI / Docker backend validation (pull_request) Has been skipped
CI / Get Changed Files (pull_request) Successful in 10s
Pull Request Labeler / labeler (pull_request_target) Successful in 4s
CI / Checkstyle Main (pull_request) Has been skipped
CI / prettier (pull_request) Has been skipped
CI / Playwright (pull_request) Has been skipped
Claude PR Review / claude-code (pull_request) Successful in 1m18s
2025-06-11 14:10:22 +02:00
6737eb9e4a
Merge pull request 'docs: Add Auth Docs' (!307) from docs/auth into main
All checks were successful
Build docs / build-docs (push) Successful in 14s
Reviewed-on: #307
Reviewed-by: Phan Huy Tran <ptran@noreply.localhost>
2025-06-11 12:02:25 +00:00
4619f787f0
add pdf to gitignore
Some checks failed
Claude PR Review / claude-code (pull_request) Successful in 26s
Pull Request Labeler / labeler (pull_request_target) Successful in 22s
CI / Get Changed Files (pull_request) Successful in 34s
Label PRs based on size / Check PR size (pull_request) Successful in 35s
CI / Backend Tests (pull_request) Has been skipped
CI / Checkstyle Main (pull_request) Has been skipped
CI / oxlint (pull_request) Has been skipped
CI / Docker frontend validation (pull_request) Has been skipped
CI / prettier (pull_request) Has been skipped
CI / Docker backend validation (pull_request) Has been skipped
CI / test-build (pull_request) Has been skipped
CI / Playwright (pull_request) Has been skipped
CI / eslint (pull_request) Failing after 13m51s
2025-06-11 13:58:26 +02:00
3ca0b5a3c4
docs: Add API and JWT acronyms to documentation 2025-06-11 13:58:25 +02:00
7 changed files with 54 additions and 1 deletions

View file

@ -6,7 +6,7 @@
*.fls
*.out
*.toc
*.pdf
## Intermediate documents:
*.dvi
*-converted-to.*

View file

@ -35,4 +35,6 @@
\acro{URL}{Uniform Resource Locator}\acused{URL}
\acro{VM}{Virtual Machine}
\acro{XML}{Extensible Markup Language}
\acro{API}{Application Programming Interface}
\acro{JWT}{JSON Web Token}
\end{acronym}

Binary file not shown.

After

Width:  |  Height:  |  Size: 92 KiB

View file

@ -2,4 +2,7 @@
\input{Inhalt/Einleitung}
\input{Inhalt/Projektarchitektur}
\input{Inhalt/CI}
\input{Inhalt/Auth.tex}
\input{Inhalt/Dice.tex}
\input{Inhalt/Coinflip.tex}

View file

@ -0,0 +1,9 @@
\section{Authentifizierung}
\label{sec:Authentifizierung}
Die Authentifizierung gegenüber der \acs{API} erfolgt über einen \acs{JWT}-Token, der dem Frontend nach Erfolgreicher Authentifizierung übergeben wird.
Authentifizierung läuft über zwei verschiedene Wege ab:
\begin{itemize}
\item \textbf{Registrierung mit username/password:} Der Nutzer füllt ein Registrierungs-Formular aus, welches die Anmeldedaten an die \acs{API} sendet. Diese validitert die Anmeldedaten und legt bei Erfolg einen neuen Nutzer an. Anschließend wird eine E-Mail-Verifizierungs-Mail gesendet. Bis der Link in der Verifizierungs-Mail nicht angeklickt wurde, ist der Nutzer nicht aktiv und kann sich nicht anmelden. Nach dem Klick auf den Link wird der Nutzer aktiviert und kann sich anmelden.
\item \textbf{Login mit username/password:} Der Nutzer füllt ein Anmelde-Formular, welches die Anmeldedaten an die \acs{API} sendet. Diese prüft die Anmeldedaten und gibt bei Erfolg einen \acs{JWT}-Token zurück. Falls kein Nutzer mit den Anmeldedaten existiert, wird der Nutzer aufgefordert einen Account zu erstellen.
\item \textbf{Login über Oauth (Open Authorization):} Der Nutzer meldet sich mit einem Oauth-Provider an, in unserem Fall Google oder Github. Das Backend leitet den Nutzer zum Oauth-Provider weiter, der die Anmeldedaten prüft und bei Erfolg den Nutzer auf die Applikation weiterleitet und einen Authorization-Code zurück gibt. Mit diesem Code holt sich die \acs{API} einen \acs{JWT} vom jeweiligen Provider und holt sich Nutzer-Informationen. Mit diesen wird dann ein existierender Nutzer eingeloggt, oder registriert falls der Nutzer noch kein Konto hatte. Anschließend wird von der \acs{API} ein \acs{JWT} generiert und an das Frontend weitergegeben.
\end{itemize}

View file

@ -0,0 +1,39 @@
\clearpage
\section{Coinflip}
\subsection{Was ist Coinflip?}
Das Münzwurf-Spiel 'Coinflip' ist ein klassisches Glücksspiel, das in seiner digitalen Umsetzung den traditionellen Münzwurf simuliert. Das Spiel basiert auf dem einfachen Prinzip einer Münze mit zwei Seiten: Kopf und Zahl. Spieler setzen auf eine der beiden Seiten und haben eine 50\%-ige Gewinnchance. Die Einfachheit des Spiels macht es zu einem idealen Einstiegsspiel für neue Nutzer der Casino-Plattform.
Im Gegensatz zu komplexeren Spielen wie Dice bietet Coinflip eine feste Gewinnwahrscheinlichkeit von 50\% und einen konstanten Multiplikator von 2x. Dies bedeutet, dass Spieler bei einem Gewinn ihren Einsatz verdoppeln, während sie bei einer Niederlage ihren gesamten Einsatz verlieren.
\subsubsection{Zufallszahlengenerierung}
Die Implementierung verwendet die Standardklasse java.util.Random zur Generierung des Münzwurfs.
Die Zufallsgenerierung erzeugt einen booleschen Wert, der anschließend einer der beiden Münzseiten zugeordnet wird.
Diese binäre Entscheidung gewährleistet die faire 50:50-Verteilung, die für ein authentisches Münzwurf-Erlebnis erforderlich ist.
\subsubsection{Spielablauf und Datenfluss}
Der Spielablauf von Coinflip folgt einem strukturierten Datenfluss zwischen Frontend und Backend. Der Controller empfängt die Spielanfrage mit folgenden Parametern:
\begin{itemize}
\item \textbf{Einsatz:} Der gesetzte Münzbetrag.
\item \textbf{Gewählte Seite:} Die vom Spieler gewählte Münzseite (Kopf oder Zahl).
\end{itemize}
Nach dem Erhalt der Anfrage führt der Controller eine Guthabenprüfung durch. Bei ausreichendem Guthaben wird die Anfrage an die Service-Schicht weitergeleitet, andernfalls wird eine entsprechende Fehlermeldung zurückgegeben.
Die Service-Klasse verarbeitet die Spiellogik in folgender Reihenfolge:
\begin{enumerate}
\item Abbuchung des Einsatzes vom Spielerkonto.
\item Generierung des zufälligen Münzwurfs (Kopf oder Zahl).
\item Vergleich zwischen gewählter Seite und Wurfergebnis.
\item Bei einem Gewinn: Gutschrift des doppelten Einsatzes auf das Spielerkonto.
\item Rückgabe des Spielergebnisses an das Frontend.
\end{enumerate}
Das Spielergebnis wird strukturiert an das Frontend übermittelt und enthält:
\begin{itemize}
\item Gewinnstatus (gewonnen/verloren)
\item Auszahlungsbetrag (bei Gewinn: 2x Einsatz)
\item Geworfene Münzseite
\end{itemize}