Repository Feedback?

1 Antwort

Vom Fragesteller als hilfreich ausgezeichnet
  1. Ungenutzte Imports würde ich entfernen.
  2. Für die Talisman-Instanz brauchst du keine extra Variable.
  3. Die db_reader.py verwendest du ja gar nicht. Eine grundsätzliche Trennung (Datenbank-Handling, Login-Logik) wäre allerdings nicht verkehrt. Die Datenbankprozesse können also ruhig in eigene Funktionen ausgelagert werden. Optional könnte man diese in einer Klasse gruppieren.
  4. Die register_user-Funktion braucht den username-Parameter nicht.
  5. Die Variablen validation_for_user, found_email und found_username werden jeweils nur für einen Programmzweig benötigt. Man könnte es auch verkürzen und die Werte konkret an die Stellen schreiben, wo sie übergeben werden sollen. Immerhin handelt es sich ja um Konstanten.
  6. Begrenze deine SQL-SELECT-Anfragen immer nur auf die Spalten, die du tatäschlich brauchst, statt pauschal alle anzufragen.
  7. Du könntest die Prüfung nach Existenz des Nutzernamens eigentlich auch via WHERE...OR-Klausel zusammenfassen. Doch das musst du mit deinen selbst gesetzten Anforderungen ausmachen.
  8. An der Stelle würde ich zudem einmal hinterfragen, wieso Nutzer sich lediglich einen Nutzernamen ausdenken müssen, um einen Account zu erhalten. Bei einer E-Mail-Adresse ist die Hemmschwelle, einen Account anzulegen, höher.
  9. Für Flask gibt es die Erweiterung Flask-Session. Du brauchst nicht selbst einen Cookie zusammenbauen.
  10. Statt Zeilenumbrüche mit br zu erzwingen, wäre es eleganter, die Felder in div-Boxen zu legen oder ein CSS Grid anzuwenden. Abstände kann man anschließend mit CSS via margin / gap setzen.
  11. Die Trigger für die Funktionen validateForm und submitForm würde ich nicht aufspalten. Nutze einfach nur das submit-Ereignis für Validation und Datenversand.
  12. Den Parameter event brauchst du in dem Fall übrigens auch nicht. Beim Aufruf der Funktionen übergibst du das globale Event-Objekt (window.event). Auf das hast du innerhalb der Funktion auch schon Zugriff.
Ich habe versucht, das Salt länger zu machen, aber ich weiß nicht, wie lang es sein sollte.

Im besten Fall ist jeder Salt-Wert einzigartig.

Die von bcrypt generierte Komplexität sollte ausreichen.

(...) und ob es Möglichkeiten gibt, es sicherer zu machen.
  1. Die SQLite-Datenbank sollte außerhalb des Webrootverzeichnis liegen, um abzusichern, dass niemand von außerhalb auf die Datei zugreifen kann.
  2. Je nachdem, was denn nun geschützt werden soll, würde ich entscheiden, ob nicht nur E-Mail-Adressen während des Login-/Registrierungsprozesses zur Identifikation eines Nutzers herangezogen werden sollen. Die tatsächliche Registrierung (Anlegen eines Accounts in der Datenbank) könnte über eine E-Mail-Bestätigung ablaufen. Aktuell könnte jemand mit einem Bot ziemlich leicht Tausende von Nutzeraccounts in nur wenigen Minuten kreieren.
  3. Hinsichtlich Bruteforcing-Attacken, SPAM-Bots, u.ä. gibt es einige Strategien, die du noch implementieren könntest (z.B. Captchas, Honeypots, CRSF-Schutz - siehe Flask-WTF).
  4. Das OWASP hat Checklisten/Empfehlungen zusammengestellt, die man beim Bau von Validationsmechanismen u.ä. heranziehen kann. Lies hier und hier.
Jamalo1234 
Fragesteller
 25.06.2023, 01:35

Wow, dass es solche Leute gibt, die sich noch diese Zeit nehmen. Danke!

0