# 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

```bash
git clone https://gitea.fhgr.ch/augsbunicola/AISE_FS26-FrontendEntwicklungProjekt.git
cd AISE_FS26-FrontendEntwicklungProjekt
```

### 2. Abhängigkeiten installieren

```bash
npm install
```

### 3. Umgebungsvariablen / Ticketmaster API

Für die Bewertung enthält die Abgabe bereits eine vorkonfigurierte `.env`-Datei, sodass die Anwendung ohne zusätzliche Konfiguration gestartet werden kann.

In einer regulären Installation muss eine eigene `.env`-Datei im Projektstamm erstellt werden:

```env
TM_API_KEY=your_ticketmaster_api_key
```

Ein kostenloser API-Key kann über das Ticketmaster Developer Portal bezogen werden:

https://developer.ticketmaster.com/

Zusätzlich ist eine `.env.example`-Datei enthalten, welche die erwartete Struktur der Umgebungsvariablen dokumentiert.

### 4. Backend-Server starten

```bash
npm start
```

Ausgabe:

```text
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

* **Frontend-Backend-Integration:** Die Kommunikation zwischen Frontend, Backend und Ticketmaster API musste zuverlässig koordiniert werden.
* **Verschachtelte Ticketmaster-Daten:** Die komplexe JSON-Struktur der API erforderte eine zusätzliche Service-Schicht zur Datenaufbereitung.
* **Modularisierung:** Mit wachsendem Funktionsumfang wurde eine klare Trennung der Verantwortlichkeiten immer wichtiger.

### Lerneffekte

* **Integration erhöht die Komplexität:** Mehrere Systeme müssen konsistent zusammenarbeiten.
* **Kleine Änderungen können grosse Auswirkungen haben:** Sichere Praktiken wie die Verwendung von `textContent` helfen, Fehler und Sicherheitsrisiken zu vermeiden.
* **Modulare Architektur verbessert die Wartbarkeit:** Klare Strukturen erleichtern Entwicklung, Fehlersuche und Erweiterungen.

---

## 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, Event-Karten-Komponente, CSS-Styling, Responsives Layout |


Die individuelle Beteiligung ist in den Git-Commits auf [gitea.fhgr.ch](https://gitea.fhgr.ch/augsbunicola/AISE_FS26-FrontendEntwicklungProjekt) nachvollziehbar.