LolYangccool Posté(e) 17 mai 2019 Partager Posté(e) 17 mai 2019 (modifié) Bonjour, Vous savez peut-être que depuis Safari 10, Apple impose un blocage de l'auto-play des lecteurs vidéos/audio présents sur les sites. Le problème est que je n'arrive pas désactiver ce blocage, qui rend inopérant le lecteur audio de ma web radio sur mon site. Même problème pour Chrome, qui a les mêmes restrictions, mais pas pour Firefox. Même si vous prenez l'adresse du flux (http://geekonmic.ovh:8000/128k.mp3) et que vous l'ouvrez dans un onglet séparé de Safari, il sera impossible de le lire. J'ai bien essayé d'aller dans les Préférences, rubrique Sites web, et d'autoriser la lecture automatique, mais rien à faire. Le blocage persiste. Avez-vous une solution simple à proposer, afin que je puisse aussi de mon côté communiquer dessus sur mon site, pour permettre aux auditeurs de lire le flux sans problème ? On peut toujours lire le flux dans iTunes, VLC ou autre, mais j'aimerai que le lecteur sur mon site soit également fonctionnel. Merci beaucoup. Edit : J'édite pour préciser une chose étrange. Si je purge l'historique de navigation de Safari, le lecteur fonctionne, pendant un certain temps. Edit 2 : J'ai trouvé une solution qui me convient ! Safari n'avait rien à voir avec le problème en fait, le problème se produisait après que j'ai accédé à l'interface de gestion de mon serveur de diffusion (Icecast), qui envoie le flux aux auditeurs. En fait, j'avais configuré l'interface de gestion en https. Le flux est en http (https à mon avis totalement inutile pour un flux audio en continu), du coup, quand je chargeais l'interface d'admin du serveur de diffusion, l'adresse passait en cache avec le protocole https renseigné. Si j'essaye de lire le flux, comme le domaine est le même, il essyait de passer par du https pour lire le flux, ce qui ne fonctionne évidemment pas puisque le flux est configuré en http et est sensé être utilisé uniquement via le protocole http. Solution, désactiver le https sur l'administration du serveur, c'est pénible, mais au moins ça fonctionne. Pour le moment je suis le seul utilisateur autorisé à consulter les statistiques donc je reste comme ça (je sais d'où je me connecte, en principe sur des réseaux sûr, donc les risques qu'on intercepte mes identifiants sont j'espère assez faibles). Modifié 17 mai 2019 par LolYangccool Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
minipapymetal Posté(e) 11 août 2019 Partager Posté(e) 11 août 2019 Le 17/05/2019 à 12:48, LolYangccool a dit : (je sais d'où je me connecte, en principe sur des réseaux sûr, donc les risques qu'on intercepte mes identifiants sont j'espère assez faibles). Salut, je me permets de remonter le topic pour apporter une précision : en utilisant HTTP en lieu et place d'HTTPS pour ton espace d'administration, tu es vulnérable à une attaque du type "man in the middle" même si tu es sûr de ton réseau local. L'attaque par imposture ARP n'est qu'une méthode parmi d'autres. Lorsque l'on envoie une requête HTTP à une IP (ou un nom de domaine) distant, celle-ci passe par tout un tas d'infrastructures réseaux avant d'arriver jusqu'à ton serveur (un petit traceroute permet d'ailleurs de voir le chemin emprunté). L'assaillant peut se trouver sur n'importe quel point de ce maillage pour te dérober les informations non chiffrées contenues dans la requête. A mon sens, il serait plus judicieux d'essayer de trouver une solution pour faire passer le flux audio par HTTPS même si le flux en lui même n'a pas besoin d'être chiffré. Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
LolYangccool Posté(e) 11 août 2019 Auteur Partager Posté(e) 11 août 2019 (modifié) il y a 59 minutes, minipapymetal a dit : A mon sens, il serait plus judicieux d'essayer de trouver une solution pour faire passer le flux audio par HTTPS même si le flux en lui même n'a pas besoin d'être chiffré. Oui ce serait mieux c'est sur, mais personne ne fait ça parce que justement c'est contraignant. Si tu regardes sur d'autres radios, même des FM qui diffusent en web radio (NRJ et autres) tu verras que leurs flux sont en HTTP de ce que j'ai vu. En fait l'idéal serait que je garde le flux en HTTP mais l'admin en HTTPS. Modifié 11 août 2019 par LolYangccool Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
minipapymetal Posté(e) 11 août 2019 Partager Posté(e) 11 août 2019 (modifié) Oui, c'est possible aussi en effet. Qu'utilises-tu comme serveur web ? En définissant un sous-domaine réservé au flux de ta webradio, tu pourrais configurer un virtual host pour l'administration qui n'accepterait que du HTTPS et un autre pour le flux sur du HTTP. Ainsi, tu protégerais ton espace d'administration. Edit > je constate que tu diffuses ton flux sur le port 8000. Du coup, tu pourrais même te passer du nom de domaine et faire deux virtual hosts qui écoutent sur des ports différents : un 443 pour ton admin en HTTPS et un 8000 qui se contente du HTTP. Modifié 11 août 2019 par minipapymetal Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
LolYangccool Posté(e) 11 août 2019 Auteur Partager Posté(e) 11 août 2019 Citation Edit > je constate que tu diffuses ton flux sur le port 8000 Oui et dans l’idéal j’aimerai diffuser sur le port 80 pour simplifier l’adresse, il ne serait plus utile de préciser le port et ça serait plus simple. Je dois regarder ça aussi. Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
minipapymetal Posté(e) 11 août 2019 Partager Posté(e) 11 août 2019 Dans ce cas, la solution du sous-domaine me parait plus appropriée avec une configuration du virtual host pour faire un proxy vers le port 8000. Ainsi, l'adresse serait simplifiée. Un autre virtual host pour ton administration en HTTPS et le tour est joué. Tu tournes sur Apache, Nginx ou autre chose ? Si besoin, je peux filer un coup de main pour la configuration. Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
LolYangccool Posté(e) 11 août 2019 Auteur Partager Posté(e) 11 août 2019 J'utilise Azuracast pour diffuser aux auditeurs, qui est un « package » comprenant entre autre un Icecast. J'utilise ça parce que ça me permet d'avoir des statistiques d'écoute de manière simple. Après si je pouvais m'en passer et utiliser un Icecast basique installé à la main sur mon serveur avec un autre service de stats ce ne serait pas plus mal... Tout ça pour dire que du coup j'imagine qu'il utilise Apache mais n'en suis pas sur. Je regarde pour repasser sur un Icecast « nu » dans l'après-midi, si je trouve un service de statistiques d'écoute auto-hébergeable ça me va. Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
minipapymetal Posté(e) 12 août 2019 Partager Posté(e) 12 août 2019 (modifié) Je ne connais pas Azuracast, mais un petit tour sur la documentation m'a donné l'impression que ça tourne dans un conteneur docker. Du coup, une architecture simple a mettre en oeuvre est d'avoir un serveur web général sur ton serveur (un apache par exemple), qui s'occupe de dispatcher toutes les entrées sur ton serveur vers les bons services. Le point d'entrée ne serait donc plus directement celui exposé par ton conteneur Docker, mais passerait par l'intermédiaire du serveur web qui renverrait vers le conteneur à l'aide du proxy. En soit, tu n'as donc pas à toucher à ton Azuracast s'il te convient. De plus, ça te permettrait de mettre en place un pare-feu qui bloque tous les ports sauf ceux explicitement autorisés. Dans le cadre de ton site et de ta webradio, tu pourrais n'autoriser que les ports 80 et 443 et limiterais ainsi l'exposition de ton serveur à l'extérieur. Grosso modo, cela ressemble à ça sauf que tu ne fais pas tourner des Tomcat. Modifié 12 août 2019 par minipapymetal Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
LolYangccool Posté(e) 12 août 2019 Auteur Partager Posté(e) 12 août 2019 C'est le travail d'un reverse proxy ça non ? Parce que j'en utilise déjà un. Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
minipapymetal Posté(e) 12 août 2019 Partager Posté(e) 12 août 2019 (modifié) Exactement ! Si tu en as déjà un, c'est lui qui doit centraliser toutes les entrées sur ton serveur (en tout cas, pour les expositions webs) et tu es parfaitement libre de configurer chacune d'elles comme tu l'entends. Par conséquent, rien ne s'oppose à ce que tu chiffres uniquement une partie des échanges en utilisant HTTPS et que tu laisses passer le reste sur du HTTP. Du coup, je ne comprends pas pourquoi tu exposes ton port 8000 plutôt que d'utiliser ton proxy inversé ? Modifié 12 août 2019 par minipapymetal Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
LolYangccool Posté(e) 12 août 2019 Auteur Partager Posté(e) 12 août 2019 Il y a 1 heure, minipapymetal a dit : Du coup, je ne comprends pas pourquoi tu exposes ton port 8000 plutôt que d'utiliser ton proxy inversé ? Le serveur qui fait tourner Azuracast n'est pas dans mon infra personnelle, c'est un serveur loué chez un prestataire pour des soucis de débit (la fibre arrive mais n'est pas encore là). Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
minipapymetal Posté(e) 13 août 2019 Partager Posté(e) 13 août 2019 (modifié) Aaah ! Je comprends mieux la problématique. Et ton espace d'administration est sur ton infra ou chez le presta ? As-tu accès à la config système chez le prestataire ? Un accès SSH ? C'est un Linux ? Modifié 13 août 2019 par minipapymetal Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
LolYangccool Posté(e) 13 août 2019 Auteur Partager Posté(e) 13 août 2019 (modifié) Oui c’est un serveur dédié. J’ai un accès root classique en SSH et c’est bien du Linux. Modifié 13 août 2019 par LolYangccool Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.