Termin 3: Sessionmanagement, Sicherheit, API-Endpunkte & Fachgespräch

In dieser Einheit implementieren Sie eine leichtgewichtige Form des Sessionmanagements. Zusätzlich sichern Sie Ihre Web-Applikation gegen grundlegende Angriffe auf eine Webseite ab und erstellen einen API-Endpunkt.

Erstes Fachgespräch

In diesem Termin wird überprüft, ob Sie sich intensiv mit Ihrem Projekt und den Inhalten der Vorlesung auseinandergesetzt haben.

Hauptinhalt des Fachgesprächs ist alles, was in Termin 1 und Termin 2 behandelt wurde. Dabei stehen insbesondere folgende Punkte im Fokus:

Verständnis Ihres Projekts und der zugrunde liegenden Idee
Verständnis des eigenen Programmcodes einschließlich Code-Struktur, Syntax und Funktionsweise
Fähigkeit, zentrale Entscheidungen im Projekt zu begründen
Verständnis der in der Vorlesung behandelten Konzepte und Methoden
Fähigkeit zu erklären, welche Inhalte aus der Vorlesung im Projekt angewendet wurden
Einordnung, wo und in welchen praktischen Kontexten diese Technologien oder Konzepte eingesetzt werden können

Sollte der Eindruck entstehen, dass diese Punkte bei beiden Fachgesprächen nicht ausreichend erfüllt sind, werden keine Bonuspunkte vergeben. Im schlimmsten Fall kann dies zudem dazu führen, dass kein Testat erteilt wird.

Vorbereitung

Machen Sie sich die Funktionsweise von Sessions in PHP klar und überlegen Sie sich, wo man Sessions einsetzen muss.
Machen Sie sich vertraut mit den Angriffen und den Gegenmaßnahmen zu Cross Site Scripting und SQL-Injection.
Überlegen Sie sich, welche Seiten von ihrem Projekt anfällig für XSS und SQL-Injection sind
Schauen Sie sich das Dateiformat JSON an und informieren Sie sich über APIs.

Aufgaben

Sessionmanagement

Der Kunde soll auf seiner Statusseite nur diejenigen Pizzen sehen, die er selbst zuletzt bestellt hat. Implementieren Sie dieses Feature mittels Sessionverwaltung.
Um es simpel zu halten: Für jede neue Bestellung soll ein neuer Session-Eintrag angelegt werden. Die vorherige Bestellung wird nicht ergänzt, sondern ersetzt.
Prüfen Sie Ihre Ergebnisse, indem Sie gleichzeitig zwei Bestellungen in unterschiedlichen Browsern – oder einmal im normalen Fenster und einmal im privaten Fenster – erstellen. So können Sie kontrollieren, ob die Session korrekt funktioniert und jede Bestellung eindeutig voneinander getrennt bleibt.
Schauen Sie sicher zusätzlich in den Dev-Tools unter Application den Cookie PHPSESSID an und versuchen Sie zu verstehen was dieser macht.
Bäcker und Fahrer sehen weiterhin alle für sie relevanten Bestellungen. Hinweis: Auf der interaktiven Demo-Seite ist dies bewusst anders umgesetzt, da sie online verfügbar ist und Datenmüll vermieden werden soll.

Authentifizierung (Freiwillig)

Achtung

Diese Aufgabe ist freiwillig und fließt nicht in die Bewertung ein.

Überlegen Sie sich, wie Sie eine einfache Authentifizierung für Bäcker und Fahrer umsetzen können.
Implementieren Sie einen Login-Mechanismus auf Basis von Sessions.
Schützen Sie die Routen /baker und /driver: Ein Zugriff ohne Login soll nicht möglich sein. Leiten Sie in diesem Fall auf die Login-Seite weiter.
Implementieren Sie zusätzlich einen Logout, der die Session löscht.
Testen Sie die Zugriffskontrolle, indem Sie die geschützten Seiten einmal mit gültigem Login und einmal ohne Login aufrufen.
Für diese einfache Übungsvariante ist keine Anpassung der Datenbank notwendig. Verwenden Sie stattdessen feste Zugangsdaten und speichern Sie den Login-Status in der Session. Alternativ können Sie auch gern die Datenbank erweitern.

Sicherheit

Verhindern Sie SQL-Injection mit Hilfe von real_escape_string oder prepared-statements. Überlegen Sie, an welchen Stellen der Anwendung ein solcher Angriff möglich wäre und verhindern Sie ihn.
Verhindern Sie Cross Site Scripting mit Hilfe von htmlspecialchars. Überlegen Sie an welchen Stellen der Anwendung ein solcher Angriff möglich wäre und verhindern Sie es.
Geben Sie in die Adresszeile folgenden String ein und schicken Sie die Bestellung ab:
```
<h1>Te"s't</h1>
```
Dieser String sollte in der Datenbank und an allen Stellen genau so gespeichert bzw. angezeigt werden und dabei zu keinem Zeitpunkt Fehler verursachen oder sogar gerendert werden.

API-Endpunkt

In der finalen Lösung der Kundenseite sollen die Statusinformationen zu den Pizzen in Echtzeit aktualisiert werden. Dies geschieht clientseitig über JavaScript, das die Daten per Fetch API regelmäßig vom Server abfragt, ohne dass die gesamte Seite neu geladen werden muss. Dafür muss es auf der Serverseite einen API-Endpunkt geben, der genau diese Rohdaten liefert (in einem Standardformat wie JSON).

In dieser Übung wird dabei nur das Lesen von Daten benötigt. Der API-Endpunkt soll also nur Anfragen per GET beantworten. Andere Methoden wie POST, PUT, PATCH oder DELETE können mit dem Statuscode 405 Method Not Allowed beantwortet werden.

Erstellen Sie dafür basierend auf unserer MVC-Architektur einen API-Endpunkt namens api samt aller benötigten Dateien und Routen. Dieser Endpunkt soll keine HTML-Ausgabe erzeugen, sondern "nur" die Daten der bestellten Pizzen im JSON-Format zurückliefern. Das können Sie realisieren indem Sie in generateResponse statt renderHtml() die Methode renderJson() nutzen. Schauen Sie im BaseController was der Unterschied ist!
Überlegen Sie sich, welche Daten der Endpunkt von der Datenbank benötigt, um die gewünschten Funktionalität zu ermöglichen.
Die Daten, die der Endpunkt benötigt, können sofern bereits ein bestehendes Model passende Methoden für diese Informationen bereitstellt – direkt daraus bezogen werden.
Testen Sie die korrekte Funktionsweise von dem Endpunkt api mittels eines direkten Aufrufs der Route /api im Browser. Je nach Browser wird die Antwort mehr oder weniger leserlich dargestellt. Alternativ können Sie den Netzwerk-Tab von den Dev-Tools nutzen.

Routing mit Path-Parametern (Freiwillig)

Achtung

Diese Aufgabe ist freiwillig und fließt nicht in die Bewertung ein.

Bislang wird der API-Endpunkt über den festen Routennamen /api angesprochen. In REST-APIs können Routen zusätzlich variable Bestandteile enthalten, zum Beispiel eine Ressource und eine ID:

/api/ordering/42

api ist dabei die Base-Route, ordering beschreibt die Ressource Bestellung. Der Teil 42 ist kein eigener Endpunkt, sondern ein Path-Parameter, der eine konkrete Bestellung auswählt. Die Route beschreibt in diesem Fall also die Bestellung mit der ID 42.

Erweitern Sie Ihr Routing so, dass nicht nur feste Routennamen, sondern auch Pfade mit zusätzlichen Parametern erkannt werden können.
Implementieren Sie eine ressourcenorientierte Route nach folgendem Muster:
```
/api/{resource}/{id}
```
Um das zu realisieren, können Sie im Router.php neue Methoden hinzufügen und bestehende ggf. anpassen.
Nutzen Sie im Controller die vom Router ermittelte Ressource und den Path-Parameter, um über das passende Model genau diese Bestellung aus der Datenbank zu laden.
Geben Sie für diese Route die Daten genau dieser einen Bestellung im JSON-Format zurück. Dazu können Sie ebenfalls renderJson() verwenden.
Beachten Sie: Durch die ID in der URL wird die Bestellung zwar eindeutig ausgewählt, die Session ist aber weiterhin für die Zugriffskontrolle sinnvoll. Prüfen Sie deshalb, ob die angefragte Bestellung auch zur aktuellen Session gehört. Sonst könnten durch das Ändern des Path-Parameters fremde Bestellungen abgefragt werden.
Testen Sie die Route direkt im Browser oder im Netzwerk-Tab der Dev-Tools.

Meilenstein

Stand jetzt sind Sessionmanagement, grundlegende Sicherheitsmaßnahmen und der API-Endpunkt umgesetzt. Damit ist das Projekt funktional vorbereitet für die clientseitige Echtzeit-Aktualisierung im nächsten Schritt.

Nachbereitung

Setzen Sie noch eventuell fehlende Teile der obigen Aufgabe innerhalb von 7 Tagen um, um Feedback via Gitlab-Issues zu Ihrem Code zu erhalten.

Ergebnisse

Die folgenden Ergebnisse müssen für eine erfolgreiche Durchführung der Praktikumseinheit vorliegen:

Ergebnisse

Der Kunde "sieht" - dank Sessions - nur noch seine eigenen Bestellungen (auf der bisherigen Kundenseite und auf dem neuen API-Endpunkt)
Implementierung vom API-Endpunkt /api basierend auf unserer MVC-Architektur.
Versenden der Statusdaten durch den Endpunkt /api mittels JSON
Absicherung der gesamten Web-Applikation gegen SQL-Injection und Cross-Site-Scripting (XSS)