Bei KH-URL-Authentifizierung sendet der Server Verbindungsdaten per POST an ein Backend und prüft dessen Antwort. Anders als die URL-Rollen von regulärem Icecast 2.5 verwendet der festgelegte KH-Stand Mount-Optionen wie listener_add, listener_remove und stream_auth. Halten Sie diese Schnittstellen auseinander.

Den Mount-Callback festlegen

Dieser Ausschnitt gehört in den ausgewählten KH-Mount. Sämtliche URLs stehen für eigene Endpunkte. Das Handbuch liefert kein Backend:

xml · Codebeispiel
<authentication type="url">
  <option name="listener_add" value="https://auth.example.org/admit"/>
  <option name="listener_remove" value="https://auth.example.org/leave"/>
  <option name="auth_header" value="icecast-auth-user: 1"/>
  <option name="timelimit_header" value="icecast-auth-timelimit:"/>
  <option name="headers" value="x-session-token"/>
  <option name="header_prefix" value="Client-"/>
</authentication>

Das Dokumentationsbeispiel schreibt headers_prefix. Die festgelegte auth_url.c implementiert jedoch header_prefix. Verwenden Sie die implementierte Schreibweise. Leiten Sie Clientheader nur bei Bedarf weiter. Der Tokenheader ist ein Beispiel und keine Aufforderung, beliebigen Clientangaben zu vertrauen.

Eine ausdrückliche Entscheidung antworten

Ein erfolgreicher Callback kann den eingestellten Zustimmungsheader mit optionalem Zeitlimit senden:

http · Codebeispiel
HTTP/1.1 200 OK
icecast-auth-user: 1
icecast-auth-timelimit: 900

Dies ist eine erklärende Antwort und keine aufgezeichnete Testausgabe. Status 200 ohne den erforderlichen Zulassungsheader ist keine Zustimmung. Lassen Sie bei Ablehnung den Zustimmungsheader weg und verwenden Sie gegebenenfalls die dokumentierte Meldungsfunktion. Senden Sie keine Freigabe während der Erzeugung einer Fehlerantwort.

Die übermittelten Daten verstehen

Hörer-Callbacks enthalten unter anderem action, Mount, Server, Port, Client-ID, Benutzer, Kennwort, IP und Agent. Bei Trennung kommt die Verbindungsdauer hinzu. Die Werte sind formular-kodiert. stream_auth prüft Quellen- beziehungsweise passende Mount-Verwaltungsanfragen. mount_add und mount_remove melden Quellenereignisse. Backend-Zugangsdaten im Authentifizierer sind von übermittelten Hörerzugangsdaten getrennt.

Begrenzen Sie den Endpunkt auf die vorgesehene Anbindung, authentifizieren Sie Aufrufer und schützen Sie sensible Felder bei Transport und Speicherung. Vermeiden Sie Zugangsdaten in Callback-Abfragezeichenfolgen. Die Erweiterung handlers betrifft parallele Callback-Verarbeitung. Ihr Erhöhen repariert kein Backend mit unzureichender Zulassungsleistung.

Den Fehlervertrag prüfen

Prüfen Sie Zustimmung, ausdrückliche Ablehnung, fehlende Header, ungültige Antwort, Verzögerung, Verbindungsfehler und Zeitlimit. Untersuchen Sie Quellen-Callbacks getrennt von Hörer-Callbacks. Vergleichen Sie Logs und tatsächliche Hörergebnisse. Kein anderer passender Mount darf die Regel umgehen. Das benötigt eine isolierte Backend-/KH-Instanz. XML-Prüfung allein belegt diese Eigenschaften nicht.

Das historische PHP-Beispiel nicht bereitstellen

Die Datei conf/icecast_auth.php verwendet entfernte PHP-Schnittstellen und setzt Zugangsdaten unmittelbar in SQL ein. Sie ist historisches Anschauungsmaterial und kein einsatzfähiges Authentifizierungsbackend. Implementieren Sie den Callback-Vertrag mit unterstützten Bibliotheken, parametrisierten Abfragen und ausdrücklicher Fehlerbehandlung. Übernehmen Sie weder Datenbank- noch Anfrageverarbeitung.