Ein URL-Authentifizierungsbackend anbinden

Bei URL-Authentifizierung fragt Icecast ein Backend, ob eine bestimmte Verbindung zugelassen wird. Dadurch entsteht eine Laufzeitabhängigkeit: Erreichbarkeit und Antwortzeit dieses Backends beeinflussen die Hörerzulassung. Dieses Portal stellt ein solches Backend weder bereit noch betreibt es eines.

Die Schnittstelle der konkreten Version verwenden

Die URL-Rollen von Icecast 2.5.0 verwenden client_add und client_remove sowie einstellbare Aktionsnamen. Ältere Dokumentation beschreibt listener_add, listener_remove und stream_auth als Konfigurationsoptionen. Deren Kompatibilitätsumsetzung ist von der aktuellen Schnittstelle zu unterscheiden.

Dieser Ausschnitt gehört in das <authentication>-Element eines Mounts. auth.example.org steht für Ihr eigenes Backend. Die URLs sind keine laufenden Dienste:

<role type="url" match-method="get,head" allow-method="get,head"
      allow-web="*" deny-admin="*">
  <option name="client_add" value="https://auth.example.org/admit"/>
  <option name="client_remove" value="https://auth.example.org/leave"/>
  <option name="action_add" value="listener_add"/>
  <option name="action_remove" value="listener_remove"/>
  <option name="header_auth" value="x-icecast-auth-result"/>
  <option name="header_timelimit" value="x-icecast-auth-timelimit"/>
</role>
<role type="anonymous" match-method="get,head" deny-all="*"/>

Der Quellcode kennt Ergebniswerte wie ok, failed, forbidden und no match. Beim eingestellten neuen Header kann eine erfolgreiche Backendantwort so aussehen:

HTTP/1.1 200 OK
X-Icecast-Auth-Result: ok
X-Icecast-Auth-Timelimit: 900

Dies ist ein erklärender Headerblock und keine aufgezeichnete Antwort. Das Zeitlimit wird in Sekunden angegeben. Ein erfolgreicher HTTP-Status ohne erforderliches Authentifizierungsergebnis darf nicht als Zustimmung vereinbart werden. Das ältere icecast-auth-user: 1 ist ein eigener Kompatibilitätsweg.

Rückrufdaten sorgfältig behandeln

Ein Callback kann Mount, Server, Port, Client-ID, Zugangsdaten, IP-Adresse und User-Agent enthalten. Die Werte sind formular-kodiert. Verarbeiten Sie Felder statt einer selbst aufgeteilten Zeichenkette. Leiten Sie zusätzliche Clientheader nur bei Bedarf über eine begrenzte Liste und einen klaren Präfix weiter. Vom Client gelieferte Header sind nicht automatisch vertrauenswürdig.

Geheimnisse gehören nicht in Callback-URLs oder gewöhnliche Zugriffsprotokolle. Begrenzen und authentifizieren Sie den Backendzugriff passend. Eine gefälschte externe Callback-Anfrage beweist keine Icecast-Sitzung. Für Benachrichtigungen über den Lebenszyklus einer Quelle sieht die neue Konfiguration Ereignisbindungen vor.

Zulassung und Fehlerfall prüfen

Prüfen Sie erlaubte und abgelehnte Konten, fehlende Ergebnisheader, ungültige Antworten, ein langsames oder unerreichbares Backend, Zeitlimits und Abmeldeaufrufe. Die vollständige Rollenkette darf keinen unbeabsichtigten anonymen Zugriff erlauben. Vergleichen Sie Backendentscheidung, Hörerergebnis und Icecast-Logs. Eine künstliche HTTP-Antwort allein prüft die Integration nicht.