Reviewed-on: #10
Encore – Event Discovery
Frontend-Projekt für das Modul cds-208 an der FHGR (Frühlingssemester 2026).
Projektbeschreibung
Encore ist eine webbasierte Event-Discovery-Plattform. Nutzer können Konzerte, Sportveranstaltungen und Kulturanlässe in jeder Stadt direkt über die Ticketmaster-API suchen und filtern – ohne sich durch überladene Buchungsportale kämpfen zu müssen.
Die drei Kernziele der Anwendung:
- Entdecken: Events nach Stadt, Datum und Kategorie filtern
- Organisieren: Interessante Events lokal speichern und in der eigenen Event-Liste verwalten
- Teilen: Andere registrierte Nutzer direkt zu Events einladen und auf Einladungen reagieren
Besondere Features
| Feature | Beschreibung |
|---|---|
| Ticketmaster-Integration | Live-Daten über einen eigenen Backend-Proxy (API-Key bleibt serverseitig) |
| Dreifachfilter | Gleichzeitig nach Stadt, Datumsbereich und Kategorie filtern |
| My Events | Gespeicherte Events in einer eigenen Ansicht mit Entfernen-Option |
| Einladungssystem | Nutzer können andere per Inline-Formular zu Events einladen und Einladungen annehmen/ablehnen |
| Vollständig responsiv | Optimiert für Mobile, Tablet und Desktop (Bootstrap-Grid + eigenes CSS) |
| XSS-Schutz | Alle nutzerkontrollierten Daten werden via textContent und DOM-Methoden gerendert (kein innerHTML mit externen Daten) |
| Accessibility (WCAG A) | Semantisches HTML5, ARIA-Labels, sichtbare Labels für alle Formularfelder, aria-live-Regionen |
Installation & lokale Ausführung
1. Repository klonen
git clone https://gitea.fhgr.ch/augsbunicola/AISE_FS26-FrontendEntwicklungProjekt.git
cd AISE_FS26-FrontendEntwicklungProjekt
2. Abhängigkeiten installieren
npm install
3. Umgebungsvariable konfigurieren
Erstelle eine .env-Datei im Projektstamm:
TM_API_KEY=dein_ticketmaster_api_key
Den API-Key erhältst du kostenlos unter developer.ticketmaster.com.
(Zum Testen ist im Repository vorübergehend ein Key hinterlegt.)
4. Backend-Server starten
node server/server.js
Ausgabe: Server läuft auf http://localhost:3000
5. Frontend öffnen
Öffne index.html direkt im Browser (kein separater Dev-Server nötig).
Tipp: Verwende die Live Server Extension in VS Code für automatisches Reload.
Verwendete Technologien, Libraries & Frameworks
| Kategorie | Technologie | Begründung |
|---|---|---|
| Markup | HTML5 (semantisch) | Strukturierung mit <article>, <section>, <nav>, <header>, <footer> |
| Styling | CSS3 (Flexbox, Grid) | Responsive Layout ohne Framework-Overhead |
| CSS-Framework | Bootstrap 5.3 | Schnelles responsives Grid, Utility-Klassen, Button-Stile |
| Sprache | Vanilla JavaScript (ES6+) | Module, Arrow Functions, Async/Await, Destructuring |
| HTTP | Fetch API | Native Browser-API für asynchrone Requests |
| Backend | Node.js + Express 5 | Leichtgewichtiger Server für API-Proxy und Nutzerverwaltung |
| Externe API | Ticketmaster Discovery API | Echtzeit-Eventdaten weltweit |
| Umgebungsvariablen | dotenv | API-Key sicher aus .env laden |
| Datenpersistenz | localStorage (Frontend) | Gespeicherte Events ohne Backend-Aufwand |
Bewusst nicht verwendet: JS-Frameworks (React, Vue, Angular) – gemäss Projektanforderungen.
Sicherheit (OWASP-Reflexion)
Im Rahmen des Projekts wurden folgende OWASP-Risiken berücksichtigt und dokumentiert:
A03 – Injection / XSS (Cross-Site Scripting)
Risiko: Nutzerdaten (Benutzernamen, Eventnamen aus der API) könnten Schadcode enthalten, der im Browser ausgeführt wird.
Massnahme: Alle externen Daten werden ausschliesslich via element.textContent gerendert – niemals via innerHTML mit ungeprüften Werten. Beim Aufbau des Einladungs-Panels werden DOM-Methoden (createElement, appendChild) statt Template-Strings verwendet.
Client-seitige Input-Validierung: Formularfelder werden vor dem Absenden geprüft – leere Pflichtfelder (Stadt, Benutzername, Passwort, Einladungs-Empfänger) werden mit einer Inline-Fehlermeldung abgewiesen und der Request wird nicht abgesendet. Ungültige Statuswerte (PUT /api/invitation/:id) werden serverseitig mit 400 Bad Request abgelehnt.
A02 – Cryptographic Failures / Sensitive Data Exposure
Risiko: Passwörter im Klartext, API-Key im Frontend.
Massnahme: Der Ticketmaster-API-Key liegt ausschliesslich serverseitig in .env – der Client sieht ihn nie. Die Passwörter werden bewusst ungehasht gespeichert (Vereinfachung für den Prototyp); in einer Produktionsumgebung würden bcrypt und JWT-Tokens eingesetzt.
A07 – Identification and Authentication Failures
Risiko: Header-basierte Authentifizierung ohne Tokens ist nicht produktionstauglich.
Massnahme: Für diesen Prototyp bewusst vereinfacht. Die Einschränkung ist dokumentiert (kein HTTPS, kein Session-Management).
Einsatz von KI-Werkzeugen
Im Projektverlauf wurden KI-Assistenten (Claude Code) eingesetzt für:
- Code-Vervollständigung und Debugging: Unterstützung bei der Implementierung des Einladungssystems und der XSS-sicheren Einladungsdarstellung
- Code-Review: Identifikation von Sicherheitslücken (XSS via innerHTML, falsche HTTP-Statuscodes)
- Dokumentation: Unterstützung beim Verfassen von JSDoc-Kommentaren und dieser README
Alle KI-generierten Vorschläge wurden kritisch geprüft, angepasst und manuell getestet. Die Verantwortung für den Code liegt bei den Entwicklerinnen und Entwicklern.
Selbstreflexion
Herausforderungen:
- Externe API-Integration: Die Ticketmaster-API hat eine komplexe, verschachtelte JSON-Struktur. Das Mapping auf ein einfaches Datenmodell erforderte sorgfältige Analyse und optionale Chaining (
?.). - Modulstruktur ohne Framework: Die klare Trennung in
api/,services/,ui/ohne ein Framework erforderte bewusste Architekturentscheidungen. - Statuscode-Konventionen: Die korrekte Verwendung von HTTP-Statuscodes (201 für Ressource-Erstellung, 200 für erfolgreichen GET) musste erst explizit reflektiert werden.
- XSS-Bewusstsein: Das Risiko von
innerHTMLmit externen Daten war nicht von Anfang an präsent und wurde erst im Code-Review erkannt.
Lerneffekte:
- Tiefes Verständnis für Async/Await und Fehlerbehandlung in JavaScript
- Sensibilisierung für OWASP-Risiken bereits beim Schreiben von Frontend-Code
- Wert von semantischem HTML5 und Accessibility für Barrierefreiheit und SEO
Gruppenmitglieder und Rollen
| Name | Rolle | Schwerpunkte |
|---|---|---|
| Nicola Augsburger | Frontend & Backend | Einladungssystem (Frontend + Backend), Authentifizierung, App-Architektur |
| Karolina Thöny-Tyganova | Frontend & API | Ticketmaster-API-Integration, Suchfunktion, Filterlogik |
Die individuelle Beteiligung ist in den Git-Commits auf gitea.fhgr.ch nachvollziehbar.