Anmerkungen von Maximilian zu Blatt 04

Ist der PHP-Code gut verständlich und übersichtlich strukturiert? Beinahe vollständig. ArticleManager::getInstance() erzeugt Dummy-Daten direkt beim Abruf der Instanz; etwas unübersichtlich, aber im Kontext der Dummy-Daten nicht zu gewichten (heißt es wird nicht negativ angerechnet).

Wie ist die Code-Qualität? Teilweise. articleAuthorValidator() ist mit TODO versehen und gibt immer true zurück. In home.php wird $dummy3->getId() aufgerufen, bevor geprüft wird, ob $dummy3 überhaupt existiert.

Wird redundanter Code vermieden? Teilweise. Die Kategorie-Listen stehen mehrfach separat in createArticle.php, updateArticle.php, navbar.php und article-validator.php. Fehlerausgaben für Artikel-Erstellung und Artikel-Bearbeitung sind ebenfalls fast identisch doppelt vorhanden.

Findet eine adäquate Trennung von PHP-Code und HTML-Code statt? Beinahe vollständig. In den Views werden teilweise noch Controller direkt eingebunden, z. B. profile.php bindet profile-controller.php ein und updateArticle.php nutzt showArticle-controller.php, um Daten zu laden (kann man theoretisch so machen, an dieser Stelle ist die Trennung dann aber nicht mehr wirklich sauber auf einem fundamentalen Level).

Ist eine Trennung in Model, View und Controller ersichtlich und auch korrekt durchgeführt? Teilweise. content-Dateien übernehmen teilweise Routing-/Controller-Aufgaben. Views binden Controller selbst ein.

Wurde das DAO-Pattern korrekt umgesetzt? Ok hier und da mit extends ein wenig fragwürdig aber kein Fehler.

Werden Sessions korrekt eingesetzt? Ok. session_start() wird mehrfach aufgerufen, z. B. in index.php, navbar.php, home-controller.php und search-results.php. Nach Login oder Registrierung wird keine neue Session-ID erzeugt (dies ist kein muss).

Findet in jedem Skript falls notwendig zunächst eine Authentifizierung angemeldeter Nutzer statt? Teilweise. createArticle-controller.php prüft bei direktem Aufruf nicht, ob ein Nutzer angemeldet ist. updateArticle-controller.php prüft ebenfalls nicht zu Beginn sauber die Authentifizierung. Die Authentifizierung liegt teilweise nur in der Formularseite, nicht im verarbeitenden Controller.

Ist bei „Eintrag bearbeiten/löschen“ sichergestellt, dass nur der Eigentümer den Eintrag verändern kann? Beinahe vollständig. Die eigentliche Aktualisierung prüft den Autor. Das Bearbeitungsformular updateArticle.php kann aber von jedem eingeloggten Nutzer mit fremder Artikel-ID geöffnet werden.

Werden in jedem Skript alle GET- bzw. POST-Parameter überprüft und ggf. auf Validität überprüft? Nein. pfad in index.php wird nicht per Whitelist validiert. id in showArticle-controller.php und updateArticle-controller.php wird nicht als gültige numerische ID geprüft. sort in search-results-controller.php wird nicht gegen erlaubte Werte validiert.

Werden bei Eingabefehlern durch den Nutzer die von ihm eingegebenen Daten bei der erneuten Formularanzeige übernommen? Teilweise. In createArticle.php wird old_category zwar gespeichert, aber nicht wieder im Dropdown ausgewählt (in updateArticle.php als TODO vermerkt). Beim Login wird die eingegebene E-Mail-Adresse nach einem Fehler nicht erneut angezeigt.

Wird eine adäquate Überprüfung von potentiellen Fehlern und Fehlerbehandlung durchgeführt? Teilweise. LocalArticleManager::saveArticle() prüft nicht, ob file_put_contents() erfolgreich war. getAllArticles() ignoriert fehlerhaftes JSON und gibt dann einfach ein leeres Array zurück. home-controller.php gibt im Fehlerfall direkt die Exception-Message aus.

Erfolgen bei Aktionen des Nutzers sowohl positive als auch negative Meldungen auf der nachfolgend angezeigten Seite? Teilweise. Nach erfolgreichem Login oder Registrierung gibt es keine sichtbare Erfolgsmeldung. Nach erfolgreicher Profiländerung gibt es ebenfalls keine positive Meldung. Beim Löschen des Accounts erfolgt nur eine Weiterleitung ohne Feedback.

Werden alle Eingabedaten beim Einbau in die HTML-Seite mit htmlspecialchars bzw. htmlentities HTML-kodiert? Beinahe vollständig. In home.php werden die Titel der Dummy-/Artikel-Links ohne htmlspecialchars() ausgegeben.

Werden alle Eingabedaten beim Einbau in eine URL mit urlencode URL-kodiert? Ok. Artikel-IDs werden mehrfach direkt in URLs eingesetzt, z. B. in profile.php, search-results.php und showCategory.php (Anmerkung: Rechne ich hier nicht negativ an). Auch die Formular-Action in updateArticle.php baut die ID ohne urlencode() in die URL ein (rechne ich ebenfalls nicht negativ an).

README.md

@@ -19,6 +19,8 @@
 - Die Suchseite und Kategorieseite packen momentan alle passenden Beiträge untereinander. Später sollen zunächst 10 
   Ergebnisse auf einer Seite angezeigt werden.
 - Wenn ein Bild aus einem Beitrag entfernt wird, dann wird noch nicht die Datei im Pfad /uploads gelöscht.
+- id in showArticle-controller.php und updateArticle-controller.php wird nicht als gültige numerische ID geprüft. 
+- sort in search-results-controller.php wird nicht gegen erlaubte Werte validiert.
 
 ## Besonderheiten des Projektes
 - Es wurde ein einfacher Beitrags-Editor erstellt. Mit diesem können Beiträge erstellt oder bearbeitet werden.