Jump to content

minipapymetal

Members
  • Content Count

    6
  • Joined

  • Last visited

About minipapymetal

  • Rank
    Nouveau membre

Recent Profile Visitors

4416 profile views
  1. minipapymetal

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

    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 ?
  2. minipapymetal

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

    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é ?
  3. minipapymetal

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

    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.
  4. minipapymetal

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

    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.
  5. minipapymetal

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

    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.
  6. minipapymetal

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

    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é.
×