Jump to content

minipapymetal

Members
  • Posts

    7
  • Joined

  • Last visited

Posts posted by minipapymetal

  1. Le 25/10/2019 à 10:22, gigatoaster a dit :

    Déjà il y n’a plus de bon développeurs , je schématise mais ils passent leur journée à copier/coller des bouts de codes provenant de StackOverflow. Ils utilisent des outils qui leur mâchent le travail et blâment la boîte où les commerciaux quand ils sont incapables de tenir les deadlines. En plus ils sont asociaux et ne savent pas communiquer correctement. Donc qu’ils reviennent aux fondamentaux et prennent leur responsabilité. 

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

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

×
×
  • Create New...