Aller au contenu

minipapymetal

Membre
  • Compteur de contenus

    7
  • Inscription

  • Dernière visite

Visiteurs récents du profil

5 412 visualisations du profil

minipapymetal's Achievements

Nouveau membre

Nouveau membre (1/6)

  1. minipapymetal

    Apple et les bugs

    Pur ramasssis de clichés. Je ne sais pas où vous avez travaillé et c'est peut-être le fruit de votre expérience, mais la réalité dans la majorité des boites est à 1 000 lieues du tableau que vous dépeignez ici. Il y a des problèmes structurels partout, des soucis d'organisation aussi et, inévitablement, de l'incompétence chez certaines personnes. Mais dire qu'il n'y a plus de bons développeurs (sous-entendu : "contrairement à mon époque"), c'est juste faire preuve d'une condescendance répugnante. Et le stéréotype du développeur associal, merci, mais je n'en connais pratiquement pas. La plupart ont une vie sociale parfaitement équilibrée. Ce genre de fascime est vraiment de la bêtise crasse, qui émane soit d'un idiot soit d'un gars frustré, mais c'est écoeurant à lire. J'espère ne jamais avoir à travailler avec des types dans votre genre.
  2. 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 ?
  3. 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é ?
  4. 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.
  5. 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.
  6. 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.
  7. 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é.
×
×
  • Créer...