Aller au contenu

Désactiver le blocage de l'auto-play de Safari


LolYangccool

Messages recommandés

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é par LolYangccool
Lien vers le commentaire
Partager sur d’autres sites

  • 2 months later...
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é. :)

Lien vers le commentaire
Partager sur d’autres sites

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é par LolYangccool
Lien vers le commentaire
Partager sur d’autres sites

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é par minipapymetal
Lien vers le commentaire
Partager sur d’autres sites

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. :)

Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

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.

archi.jpg

Modifié par minipapymetal
Lien vers le commentaire
Partager sur d’autres sites

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é par minipapymetal
Lien vers le commentaire
Partager sur d’autres sites

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à).

Lien vers le commentaire
Partager sur d’autres sites

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.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

Chargement
×
×
  • Créer...