kluckow / netspy Goto Github PK

Hier wird ein DefaultListModel verlangt.
Hier kann vermutlich die getBlacklist()-Methode im EmailHandler verwendet werden, um an die liste heranzukommen.
Zum Hinzufügen, also Schreiben in die Datei gibt es schon eine Methode im TextWriter, erreichbar über FileManager.
Bräuchten also noch eine Methode zum Editieren, also Schreiben mit bisschen Extra-Code.
Und hierfür werden wir wohl auch das Layout des NetSpyFrames anpassen müssen, da das alles hier Platz in Anspruch nimmt. 😭
Also:

• Anzeige der Blacklistwörter in einer Liste (selektierbar, single_selection_mode)
• Editier-Möglichkeit eines Wortes
• Lösch-Möglichkeit eines Wortes und aller Wörter
• Hinzufügen-Möglichkeit eines Worters

Komplettes Refactoring zum Abschluss hin.
-Kommentare, Formatierung, etc.

Im Moment ist das mit dem Pfad-Handling noch etwas unklar, ob nun mit dem absoluten oder relativen Pfad einer Datei / eines Verzeichnisses gearbeitet wird. Von daher mein Vorschlag: Ausschließlich mit absoluten Pfaden arbeiten, sofern der Pfad auf irgendeine Art und Weise verwendet wird.
Sprich wenn irgendwelche Pfade in Methoden gegeben werden:
➡️ file.getAbsolutePath() (C:......\blacklist.txt)

Wenn man über die GUI den Scan 2-mal startet bekommt man eine NullPointerException.
Weiß gerade noch nicht wieso. Man bekommt allerdings Output in der Konsole. Also testen und beheben.

• Behoben

Wäre vielleicht nicht schlecht das Security Level konfigurierbar zu machen.
So von mindestens 1 bis beliebig hoch.

Option 1) (mehr Arbeit)
Eine JMenuBar wäre dafür cool. Da könnte man dann auch andere Sachen reinpacken, wenn nötig.
Da hätte man dann oben in der Leiste einen Punkt "Konfiguration...", klickt man die Konfiguration taucht ein kleines Fenster auf mit einem JSpinner (glaube das ist die Komponente für so nen Number-Chooser).

Option 2) (weniger Arbeit)
Unter den Pfad-JTextFields einen JSpinner einfügen.

Vote:

• Option 1
• Option 2
• Lassen wir das einfach weg, ist ja nicht gefordert

Also, ich habe mal versucht die verdächtigen Emails zu analysieren. Allerdings war das nicht so einfach. Ich habe die Vermutung, dass diese ConcurrentModificationException, die wir ignorieren, für Probleme sorgt.

Außerdem ist die hitMap mit den gefundenen Blacklist-Wörtern auch blöd gespeichert.

Wir sollten also mal überlegen, ob wir da etwas an der Struktur ändern, sprich die Email-Objekte auf anderem Wege sichern unter dem Aspekt, dass man diese Email-Objekte (vollständig) loggen kann.

Die singletons sind eigentlich überflüssig und sollten daher durch herkömmliche klassen ersetzt werden.

Bevor das Projekt abgegeben wird, sollten wir alle Anwendungsfälle nochmal manuell testen, sobald wir es als fertig empfinden. Hätte ja gerne Unit-Tests gemacht, einfach so als Übung, aber dafür bleibt leider keine Zeit mehr, so wie es aussieht 😢

Am besten machen wir das Klassendiagramm nochmal komplett neu.
Vielleicht taugt dieses plugin für eclipse ja etwas.

Ich denke es würde es etwas strukturierter machen, wenn die Main-Methode in eine neue Klasse "Main" gesetzt wird. Und der momentane NetSpy wird dann zu einer normalen Klasse. Dadurch kann die Verwendung der Logbox besser und konsequenter durchgeführt werden.

Ich hab mir so gedacht so sachen wie:

• [BLOCKING]
• [INFO]
• [IMPL]
• [DOC]

an den Anfang des Ticket-Namens zu setzen wäre sinnvoll, da es ja dafür irgendwie keine Option gibt.

(Close wenn gelesen)

Schritt 1) wäre die Button-Namen public static im MyJFrame zu setzen und entsprechend zu verwenden.
Im Schritt 2) muss dann der MyActionListener erstellt werden. Dazu die überschriebene Methode actionPerformed. In dieser wird dann in einer switch-case auf Button Clicks, je nach Button Name, reagiert.
Aktuell folgende TODOs:

• Start Scan Button fehlt noch im FileChooserActionListener
• Implementierung der Funktionalitäten der 5 Button im FileChooserActionListener:

➡️

• Mail Path (inkl. File/Dir Validation)
• Blackword Path (inkl. File Validation)
• Log Path (inkl. Dir Validation)
• Quarantine Path (inkl. Dir Validation)
• Validierung auf "blacklist.txt"-Dateien beim Auswählen der Blackword-Datei (Datei muss "blacklist.txt heißen)
• Validierung auf special characters bei den directories für Quarantäne- und Log-Verzeichnis (mal schauen, ob das überhaupt notwendig ist)
• Start Scan (hier muss nur geprüft werden, ob alle Input-Felder für die Pfade != null oder != "" sind)
• Alle Pfade werden beim Auswählen über den JFileChooser in der config.properties gesetzt
• In den TextFields eingegebene Pfade, die noch nicht existieren, müssen erstellt werden
• Log-Verzeichnis UND LogDatei-Name müssen editierbar sein (und Anpassungen im Listener/FileManager werden nötig sein, denke ich)

@niinhu
Habe in den letzten Tagen diverse Änderungen vorgenommen.
Am besten einfach mal den gesamten Code anschauen.
Die NetSpy.java ruft nun das Main Window auf, der Scan Button kann auch schon genutzt werden.
Wird langsam 😃

Bei Fragen einfach über WhattsApp oder hier. Können uns auch mal wieder über TS zusammensetzen und drüberschauen.

Wenn du up-to-date bist kannste das Ticket einfach closen.

• Ich schwöre, ich habs mir angeschaut 😄

(Close wenn gelesen)

Hier eine Liste die wir bei Formatierung, etc. beachten müssen:

• max. XX Zeichen pro Zeile
• Kommentare an alle Klassen/Interfaces/etc.
• Kommentare an alle Methoden/Konstruktoren
• Kommentare an alle Instanzvariablen
• Kommentare an alle nicht-trivialen Code-Blöcke
• was noch?

Hier müssen alle public-modifiers an public static final Instanzvariablen und Methoden überprüft werden.
Man kann in Eclipse Variablen mit dem Cursor fokussieren und dann Strg+Alt+H drücken, um sich die Call Hierarchy anzeigen zu lassen.
Wird eine Methode/Variable auch außerhalb verwendet, kann der Access Modifier ruhig public bleiben.
Wird eine Methode nicht außerhalb verwendet, soll sie auf private gesetzt werden. Wird diese private-Variable/Methode in dieser Klasse dann auch nicht verwendet, so kann sie komplett gelöscht werden.
Tip: Manchmal geht es schneller bei vermuteten überflüssigen public-Modifiers einfach mal auf private setzen und schauen, in welchen Klassen Eclipse dann die Errors anzeigt. Wenn Errors angezeigt werden, bleibt es halt public.

Habe btw schon die word-Datei dafür erstellt, einfach mal anschauen.
Folgende TODOs beinhaltet die Doku:

• Tabelle für Basisfunktionalitäten abarbeiten/abhaken
• Tabelle für optionale Funktionalitäten abarbeiten/abhaken
• Klassendiagramm als PNG oder so einbringen
• Installationshinweise einfügen

sprich:
super(msg + System.lineSeperator());
Bin mir nicht ganz sicher wegen Syntax, also vorher nochmal überprüfen.

NetSpy 2.0:

• Auswahl der Verzeichnisse/ Einzelne Emails/ Dateien
• Anzeige der Pfade
• Alle Laufzeitfehler werden abgefangen und per JOptionPane ausgegeben

Technische Doku:

• Soll-/IST-Vergleich
• Klassendiagramm
• Installationshinweis

Zur Abgabe bereit:

• Lauffähiger NetSpy 2.0 inkl. Quellcode
• Dokumentation

Habe festgestellt, dass TODOs die in nachkommenden Posts sind, garnicht auf der Hauptseite ersichtlich sind. Von daher immer in den obersten Post mit reintun/hinzufügen.

(Close wenn gelesen)

Also habe nochmal bischen recherchiert und herausgefunden, dass es so gängig ist, dass man die GUI-Komponente, die man in einer Nicht-GUI-Komponente benötigt, dieser Nicht-GUI-Komponente einfach im Konstruktor übergibt. Also Beispiel hätten wir da den NetSpyActionListener, der ja das Frame im Konstruktor benötigt. Da können wir ja schon "anständig" auf die LogBox zugreifen.

Jetzt ist die Aufgabe für alle Klassen, die jegliches in die LogBox schreiben wollen, den Konstruktor so anzupassen, dass dort die LogBox benutzt werden kann (am besten als Instanzvariable sichern).

Dann wären solche Aufrufe möglich:
this.logbox.append("Scan abgeschlossen.");

Das ist aber eher nen laufender Prozess, ähnlich wie die Laufzeitfehler in JOptionPane's ausgeben.

Aber wir sollten das wenigstens an irgendeiner Klasse mal testen...EmailHandler am besten, der braucht das am ehesten.

@kevin
Dein GUI Code wäre dann die Basis.

Die Listener müssen hier noch implementiert werden.

Hier nochmal schauen wie das Format der Logs aussehen soll und dann entsprechend im Code anpassen.

• Format der Logs definieren
• Paar mal testen

alle branches bis auf master und release_branch löschen.

Momentan werden sich die Indices der Emails, die nicht verdächtig sind, gemerkt. Und später, kurz vor dem Verschieben der verdächtigen Mails, werden nur die Mails in den Quarantäne-Ordner verschoben, die nicht diesen nicht verdächtig Flag enthalten. Sprich man denkt um eine nicht vorhandene Ecke...
Also ➡️ Index verdächtiger Emails merken und diese dann verschieben!

• NotificationPopups (extends JOptionPane) für jegliche Fehlermeldung, hier werden beim Instanziieren einfach Strings mitgegeben und damit eine kleines Fenster mit der entsprechenden Message ausgegeben.
  Für die Typen "Error" und "Info" sollte vorerst eine Klasse erstellt werden, die von dem NotificationPopup erbt.