J'ai pris beaucoup de temps à chercher des réponses et croyez-moi j'ai tout essayé. J'exécute un serveur nginx qui pousse les flux rtmp vers les flux HLS.nginx - Essayer de sécuriser un flux HLS via auth_request
Voici une partie de mon nginx.conf
location /hls {
types {
application/vnd.apple.mpegurl m3u8;
}
root /mnt/;
set $auth_request_uri "http://SERVER:8000/auth_ext.php?token=$arg_token";
auth_request /auth/;
add_header Cache-Control no-cache; # Prevent caching of HLS fragments
add_header Access-Control-Allow-Origin *; # Allow web player to access our playlist
}
location /auth/ {
internal;
proxy_pass $auth_request_uri;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
Je suis en train d'authentifier un flux via une page php, où je reçois les paramètres de l'URL et répond alors 200 OK si elle correspond à un jeton dans ma base de données.
Jusqu'ici, j'ai réussi à m'authentifier, ce qui signifie que je peux accéder au http://SERVER:8080/hls/stream.m3u8?token=TOKEN si le jeton correspond, mais voici ce qui se passe.
J'ai un flux principal de m3u8 qui adapte les flux en fonction de la bande passante, et lorsque j'accède stream.m3u8 dans la console, je vois ce
http://SERVER:8080/hls/stream.m3u8?token=TOKEN
http://SERVER:8080/hls/stream_mid.m3u8
http://SERVER:8080/hls/stream_hd720.m3u8
http://SERVER:8080/hls/stream_src.m3u8
où les trois derniers m3u8 répond 404 parce que les paramètres DonT passer à travers, donc j'ai un flux qui ne se charge jamais, mais l'URL répond. De plus dans les m3u8 eux-mêmes, les fichiers .ts obtiennent également 404.
Comment faire face à cela à chaque fois qu'un premier appel à la première m3u8 est authentifié, le m3u8 restant et les fichiers ts peuvent être consultés ou retourner un 200 code?
J'espère vraiment que je me suis fait clair, je peux fournir plus de détails
Merci à tous