TODO.txt

[] JavaScript Klassen überdenken (Werden im jetztigen aufbau so eigentlich garnicht benötigt sondern nur die Funktionen)
[X] JavaScript bei allen Funktionen die mit der API arbeiten den wert <response> -> <info> -> <status> kontrollieren. Alles gut= OK. Nicht gut= ERROR. Bei Error wird zudem im info <message> mitgesendet.
[] JavaScript eingaben beim bearbeiten kontrollieren
[X] JavaScript beim löschen eines Pools überprüfen ob dieses mit einem Backup verknüpft ist
[X] Redirects funktionieren nichtmehr korrekt => Wenn eingeloggt direkt weiterleiten an /panel/index.html wenn nicht eingeloggt weiterleiten an index.html.
[X] API überprüft noch nicht welcher USER die Anfrage sendet! User kann also Fremde Backups / Pools etc. Löschen!!
[X] CSS Für die Einstellungen (Backups Pools etc)
[X] Passwort vergessen beim Login
[] Webinterface Settings um Passwort, E-Mail-Adresse zu ändern etc.
[] Webinterface Settings für den Admin zusätzliche die werte der Tabelle 143_options.
[X] Tasks / Queue Logik überdenken (Bisher: DB mit waiting, running, failed und dem Interval / lastrun. Tasks jeweils in einem Thread (damit mehrere gleichzeitig können))
[] Webserver und API: Sessions nach einer gewissen Zeit löschen
[] Website aufbau dauert mir zu lange (Vermutlich im zusammenhang mit den JS Funktionen. Bei einer API Abfrage macht JS 2 Abfragen. Die erste wird benötigt um den Header X-APIPORT zu holen. Gibt es eine andere Möglichkeit (zb. in web/js/tasks.js => get_runningtasks()))
[] Sessions auch in der Datenbank abspeichern ? (Admin könnte user rauswerfen etc)
[X] Im Webinterfaces beim bearbeiten poolid mit dem Pool Namen ersetzen und dropdown als auswahl
[RUNNING] Kompression implementrieren
[] Verschlüsselung implementrieren
[RUNNING] Überlegen: Wenn ein Backup Komprimiert (ZIP) ist: Wie vergleichen mit den aktuellen Daten (hash, binary) ? Zuerst alles Entpacken und vergleichen oder kann man die Funktionen direkt im Zip irgendwie starten ? Stimmen die Hashes etc. dann (Komprimierte Datei vs Originale Datei ja eigentlich nicht)?
[RUNNING] Backup Logik (bin/both/backup.py)
[] CIFS FileSystem integrieren (bin/both/fs_cifs.py)
[] FTP FileSystem integrieren (bin/both/fs_ftp.py)
[RUNNING] Local FileSystem integrieren (bin/both/fs_local.py)
[] NFS FileSystem integrieren (bin/both/fs_nfs.py)
[RUNNING] SFTP FileSystem integrieren (bin/both/fs_sftp.py)
[] SMB FileSystem integrieren (bin/both/fs_smb.py)
Alle FileSystems sollten immer dieselbe Logik / denselben Aufbau haben (connenct(), get_tree(), get_hash()) usw. In backup.py dann je nach ausgewähltem 'system' von der DB das richtige File importieren import bin.both.fs_xy as source // source.connect() usw.
[] Script wie ein Service starten (start/stop/restart/status) mit Lock File etc. Script soll dann im Hintergrund laufen ohne direkten output.
[X] Wie soll die Logik hinter incremental, Full etc. aussehen ? Extratask für Full und Incremental ? Soll das das Skript selbst überprüfen / wann war das letzte Full Backup ? Vermutlich benötigen wir noch eine extra Spalte in 143_backup (da habe ich bisher nicht daran gedacht)
[] Restore Skript (bin/both/restore.py)
[] Webserver: Sessions verschlüsseln (OpenSSL ?)
[] Webinterface: Backup Manuell starten
[] Webinterface: Pools zugriff test Funktion (zum testen ob beispielsweise FTP Zugangsdaten stimmen etc.)
[] Speedanzeige / Etwaige Zeitdauer bei laufenden Tasks
[] Restore: Möglichkeit einzelne Dateien oder ganzes Backup zurückzuspielen
[X] Webinterface: Möglichkeit vergangene Logs anzuzeigen
[] Prozesse: Möglichkeit laufendes Backup zu stoppen / (Pausieren?)
[] Virencheck mit VirusTotal API (Gibt laut Auftrag extrapunkte).  (Bulk beispiel da API auf 4 Anfragen / min begränzt: https://github.com/botherder/virustotal/blob/master/vt.py)
[] Virencheck als option bei Backups hinzufügen (DB + Webinterface)
[] Skript für Windows unter Dienste hinzufügen (mit PyWin32)
[X] Prüfen ob Skript als root / Administrator gestartet wurde (Besser wegen Dateiberechtigungen)
[] SQL INJECTION verhinden (bin/both/dbcon.py). Korrekt wäre es wenn man die Variablen nicht direkt im SQL Befehl verwendet wie bei OOP PHP. Jedoch müsste man dann die Funktion query() umschreiben und kp wie am besten.
[] Code vereinheiltichen. Teilweise werden returns von FUnktionen direkt verwendet, teilweise als Variable definiert und die Variable verwendet.