ADR hinzugefügt

Author: GalacticCodeGambit

Project/Frontend/package-lock.json

@@ -0,0 +1,26 @@
+# AD01: Sichere Passwortspeicherung in der Datenbank via Hash & Salt
+
+## Kontext und Problemstellung
+
+Bei der Registrierung bei LazyCook werden Email und Passwort des Nutzers erfasst und in einer Datenbank gespeichert. Zur Sicherung der gespeicherten Daten und zum Schutz des Kontos darf das Passwort nicht im Klartext in der Datenbank abgelegt werden. Es stellt sich die Frage wie das Passwort verschlüsselt und in der Datenbank gespeichert werden soll. Das Hashverfahren kann bei Unsicherheit vom Entwickler geändert werden.
+
+
+## Betrachtete Varianten
+
+* SHA-256
+* SHA-256 mit Salt
+* PBKDF2-HMAC mit SHA256
+
+## Entscheidung
+
+Gewählte Variante: PBKDF2-HMAC mit SHA256, denn diese ist im Vergleich zu SHA-256 und SHA-256 mit Salt wesentlich sicherer. SHA-256 kann mit den heutigen Grafikkarten sehr schnell berechnet werden. PBKDF2-HMAC mit SHA256 berechnet den Hasshwert tausende male wodurch es für Angreifer sehr schwer ist diesen mit BruteForce zu berechnen. Zudem wird ein Salt verwendet und sie ist gegen Rainbow-Tables abgesichert. Des weiteren wird dieses Verfahren von der python eigenen hashlib-Bibliothek unterstützt. Gespeichert wird das gehashete Passwort und der Salt mit base64.
+
+## Status
+
+Angenommen
+
+## Konsequenzen
+
+* Gut, weil die Sicherheit der Daten damit garantiert ist und das Passwort nicht im Klartext sondern entsprechend fester Standards verschlüsselt wurde
+* Der Passwortvergleich bei Anmeldung ist dadurch entwas komplexer. Das Salt muss aus der Datenbank abgefragt werden und das eingegebene Passwort muss mit diesem gehashed werden und mit dem gespeicherten Passwort verglichen werden. Es kann in der Bibliothek auch auf ein anderes Hashverfahren zugegriffen werden. 
+

docs/adr/ADR01.md

@@ -0,0 +1,25 @@
+# AD02: Intuitive Nutzbarkeit der Anwendung über begrenzte Schritte bis zum RecipeFinder
+
+## Kontext und Problemstellung
+
+Der Nutzer sollte mit möglichst wenigen Schritten vom Aufruf der Website zum RecipeFinder kommen.
+
+## Betrachtete Varianten
+
+* Direkte Weiterleitung von Registrierung zu RecipeFinder
+* Weiterleitung erst nach Anmeldung zu RecipeFinder
+
+## Entscheidung
+
+Gewählte Variante: Direkte Weiterleitung von Registrierung zu RecipeFinder. Erhört die Attraktivität und Benutzerfreundlichkeit, vermeidet unnötige Schritte des Benutzers.
+
+## Status
+
+Angenommen
+
+## Konsequenzen
+
+* Gut,denn der Benutzer freut sich über die gesparte Zeit und bessere Benutzererfahrung.
+
+
+

docs/adr/ADR02.md

@@ -0,0 +1,29 @@
+# AD03: Produktive Nutzbarkeit durch Verhinderung von Informationsüberladung
+
+## Kontext und Problemstellung
+
+Der Nutzer sollte nicht zu viele Informationen auf der Website gleichzeitig sehen um nicht überfordert zu werden.
+
+## Betrachtete Varianten
+
+* Maximal 20 Rezeptvorschläge
+* Maximal 3 Rezeptvorschläge auf einer Seite und Scrolling bis maximal 10 Vorschläge
+* Maximal 10 Rezeptvorschläge
+* 3x3 Matrix
+* Listenasicht 
+* Blockansicht
+
+## Entscheidung
+
+Gewählte Variante: 3x3-Matrix. Eine 3x3 Matrix gibt dem Benutzer eine angenehme Anzhal von Rezepten, die er auf einen Blick erfassen kann. Die einzelnen Rezeptkacheln sind groß genug für Bilder und weitere Rezeptinfos. Eine maximale Begrenzung ist nicht nötig, da dafür noch nicht genügen Elemente in der Datenbank enthalten sind.
+
+## Status
+
+Angenommen
+
+## Konsequenzen
+
+* Gut, dem Nutzer werden nicht zu viele Rezepte zeitgleich angezeigt, die Rezeptinfos sind gut zu erkennen.
+* Schlecht, bei zu vielen passenden Rezepten in der Datenbank gibt es keine Begrenzung bezüglich der maximalen Anzahl was zu langen Ladezeiten führen kann.
+
+

docs/adr/ADR03.md

@@ -0,0 +1,30 @@
+# Architekturentscheidungen
+
+## Kontext und Problemstellung
+
+Welcher Architekturstil soll für das Projekt verwendet werden? Um eine einheitliche Umsetzung im gesamten Projekt zu gewährleisten, die auch im zeitlich realisierbar ist. 
+
+
+## Betrachtete Varianten
+
+* Schichtbasierter Architekturstil
+* Servicebasierter Architekturstil
+* Eventbasierter Architekturstil
+* "Space-based" Architekturstil
+* Microservices Architekturstil
+* MicrokernelArchitekturstil
+
+## Entscheidung
+
+Gewählte Variante: "Schichtbasierter Architekturstil", da diese einfach umzusetzen ist und die Verantwortlichkeiten klar trennt.
+
+## Status
+
+Angenommen
+
+## Konsequenzen
+
+* Gut, weil es einfach und leicht umzusetzen ist. <!--jeder Entwickler weiß wie LazyCook aufgebaut sein soll im Frontend und Backend sowie die Kommunikation zwischen diesen--> 
+* Gut, weil es eine klare Trennung der Verantwortlichkeiten vorgibt. 
+* Schlecht, weil es weniger Fehlertoleranz gibt.
+* Schlecht, da die Skalierbarkeit und Testbarkeit geringe sind.

docs/adr/ADR04.md

@@ -0,0 +1,29 @@
+# Designprinzipien
+
+## Kontext und Problemstellung
+
+Welcher Designprinzipien soll für das Projekt verwendet werden? Um eine einheitliche Umsetzung im gesamten Projekt zu gewährleisten. 
+
+
+## Betrachtete Varianten
+
+* Single Responsibility Principle (SRP)
+* Open-Closed Principle (OCP)
+* Liskov Substitution Principle (LSP)
+* Interface Segregation Principle (ISP)
+* Dependency Inversion Principle (DIP)
+
+## Entscheidung
+
+Gewählte Variante: "Liskov Substitution Principle (LSP)", denn damit stellen wir sicher, dass sich alle unsere Speicher-Implementierung gegenüber der Geschäftslogik gleich verhalten. Diese Variante, erlaubt uns es die Datenquelle später auszutauschen, ohne den Code im Service ändern zu müssen
+
+## Status
+
+Angenommen
+
+## Konsequenzen
+
+* Gut, weil die Wartbarkeit erhöht wird. 
+* Gut, weil die Testbarkeit verbessert wird.
+* Schlecht, weil der initiale Entwicklungsaufwand leicht steigt, da wir erst Interfaces definieren müssen, bevor wir die Logik implementieren können.
+* Schlecht, weil wir beim Design der Schnittstellen sehr sorgfältig sein müssen, um sicherzustellen, dass zukünftige Implementierungen (z. B. eine API, die Netzwerkfehler werfen kann) das Prinzip nicht verletzen.

docs/adr/ADR05.md

@@ -0,0 +1,28 @@
+# {Kurzer Titel, der das gelöste Problem und die gefundene Lösung beschreibt}
+
+## Kontext und Problemstellung
+
+{Beschreibt den Kontext und die Problemstellung, z.B. in zwei bis drei Sätzen freiem Text oder in der Form einer Geschichte, die das Problem veranschaulicht. Eine gute Form, das Problem auszudrücken, ist auch eine Frage. Ggf. noch Links zu Boards oder Ticketing System.}
+
+
+## Betrachtete Varianten
+
+* {Titel der Variante 1}
+* {Titel der Variante 2}
+* {Titel der Variante 3}
+* … <!-- Anzahl der Varianten kann variieren -->
+
+## Entscheidung
+
+Gewählte Variante: "{Titel der Variante 1}", denn {Begründung, z.B. die einzige Variante, die kein Ausschlusskriterium beinhaltet |  … | am besten abschneidet (siehe unten)}.
+
+
+## Status
+<!-- Eine Entscheidung kann „vorgeschlagen“ werden, wenn die Projektbeteiligten ihr noch nicht zugestimmt haben, oder „angenommen“, wenn sie angenommen wurde. 
+     Wenn ein späteres ADR eine Entscheidung ändert oder aufhebt, kann sie als „veraltet“ oder „überholt“ mit einem Verweis auf ihre Ersetzung gekennzeichnet werden. -->
+
+## Konsequenzen
+
+* Gut, weil {positive Konsequenz, z.B. Verbesserung einer oder mehrerer gewünschter Eigenschaften, …}
+* Schlecht, weil {negative Konsequenz, z.B. Einschränkung einer oder mehrerer gewünschter Eigenschaften, …}
+* … <!-- Anzahl der Konsequenzen kann variieren -->