Product Logo
Tools & Services

Feedback-System

Diese Seite erklärt, wie das Feedback-System funktioniert — vom Formular auf der Webseite bis zum GitLab-Issue.

Ablauf

Formular → Proof-of-Work → Feedback-Server → GitLab-Issue

1. Formular

Das Feedback-Formular wird am Seitenende (vor dem Footer) gerendert, wenn feedback in der Theme-Konfiguration oder über CLI-Parameter konfiguriert ist. Die Felder sind dynamisch konfigurierbar — mindestens email und message sind erforderlich.

2. Proof-of-Work

Bevor das Feedback abgesendet wird, muss der Client eine kryptografische Aufgabe lösen. Das verhindert automatisierten Spam ohne Captcha:

  1. Client fragt beim Feedback-Server eine Challenge an (/challenge-Endpoint)
  2. Server antwortet mit { challenge, salt, difficulty }
  3. Client iteriert von 0 bis difficulty und berechnet SHA-256(salt:i) für jeden Wert
  4. Sobald der berechnete Hash mit der Challenge übereinstimmt, ist die Lösung gefunden
  5. Die Lösung (challengeSolution) wird zusammen mit den Formulardaten gesendet

Dieser Proof-of-Work-Mechanismus ist für Nutzer:innen unsichtbar und dauert typischerweise wenige Sekunden.

Das Verfahren basiert auf dem von Adam Back formalisierten Hashcash-Algorithmus (2002) und folgt dem Challenge-Response-Muster nach Juels & Brainard (Client Puzzles, NDSS 1999). Die Grundidee — rechnerischer Aufwand als Spam-Bremse — geht auf Dwork & Naor (Pricing via Processing, CRYPTO 1992) zurück.

3. Feedback-Server

Der Feedback-Server ist ein eigenständiger Dienst, der:

  • Die Proof-of-Work-Lösung validiert
  • Die Formulardaten entgegennimmt
  • Ein GitLab-Issue im konfigurierten Projekt erstellt
  • Die Issue-URL an den Client zurückgibt

4. GitLab-Issue

Das erstellte Issue enthält:

  • Titel: Automatisch generiert aus dem Feedback-Inhalt
  • Beschreibung: Die Nachricht der Nutzer:in
  • Labels: Die in der Konfiguration definierten Labels
  • Seitenpfad: Die URL der Seite, auf der das Feedback abgegeben wurde
  • Vertraulichkeit: Optional als vertrauliches Issue (shouldCreateConfidentialIssue)

Öffentliche vs. vertrauliche Issues

Standardmäßig werden öffentliche Issues erstellt. Das bedeutet: Feedback ist für alle sichtbar, die Zugriff auf das GitLab-Projekt haben.

Wenn shouldCreateConfidentialIssue: true gesetzt ist, werden Issues als vertraulich markiert — nur Projektmitglieder sehen sie.

Bei öffentlichen Issues (shouldCreateConfidentialIssue: false) sollte ein notice-Block konfiguriert werden, der Nutzer:innen darauf hinweist, dass ihr Feedback öffentlich sichtbar ist. Dies ist immer dann der Fall, wenn das GitLab Repository öffentlich zugänglich ist.

Konfigurationsebenen

Das Feedback-System kann auf zwei Ebenen konfiguriert werden:

Easy Mode

Drei CI-Parameter aktivieren das Feedback:

  • feedback-gitlab-project-id — Projekt-ID
  • feedback-server-url — Server-URL
  • feedback-issue-link — Link zur Issue-Seite

Optional: feedback-title und feedback-description für Titel und Beschreibung des Formulars.

Developer Mode

Der feedback-Block in der theme.config.tsx bietet volle Kontrolle: benutzerdefinierte Felder, Styling-Klassen, Datenschutz-Einwilligung, Notice-Block und manuelle Platzierung per <Feedback />-Komponente.