Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 149 sur 154 PremièrePremière ... 4999139141142143144145146147148149150151152153154 DernièreDernière
Affichage des résultats 4 441 à 4 470 sur 4614
  1. #4441
    Citation Envoyé par William Vaurien Voir le message
    Et j'aurais aimé en savoir un peu plus (juste un peu, pas un article de blog) sur comment passer d'un dev avec Spring (ou JEE) en monolithe ou micro-service à un dev serverless avec "juste des méthodes".
    En gros ces méthodes ont des déclencheurs. Par exemple, pour les google functions, c’est soit une requête http, soit un message Pub\Sub.
    Le gros intérêt c'est de déléguer complètement à l'infrastructure Cloud tout le bordel d'infrastructure justement.Rien ne t'empêche de réimplanter la totalité de ton application au sein d'une seule méthode mais bon. a serait un peu dommage
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  2. #4442
    Citation Envoyé par William Vaurien Voir le message
    c'est intéressant et intriguant ton commentaire Kamasa, tu pourrais détailler comment ça se passe une appli sans serveur ? Je suis aussi habitué à Spring/SpringBoot que je connais suffisamment bien pour servir de référent pour mon équipe alors qu'en fait j'ai juste lu (et compris) un peu la doc. Je suis à l'aise avec (sauf Spring Secu que je trouve ... cryptique et Spring Batch qui est bien trop compliqué pour le service rendu dans notre cas) et du coup j'ai du mal à imaginer faire sans...
    Citation Envoyé par Teocali Voir le message
    Kamasa, tu m'interromps si je dit de la merde, mais en gros, le serverless, c'est une application par fonction (pour faire simple) que tu refiles a un herbergeur cloud, et c'est lui qui s'occupe de tout le boiler plate : Scale up/scale Down, hebergement, routage, et tutti quanti. Y'a toujours un serveur, of corse, mais c'est absolument plus toi qui t'en occupes. En tout cas, c'est comme ça que j'ai compris le truc. Les technos derrières, c'est les lamba pour AWS et Google Functions pour Google cloud.
    C'est effectivement ça. Sauf peut être pour le serveur qui tourne chez l'hébergeur Cloud, là j'ignore comment ils choisissent de gérer ça.
    Mais concrètement (pour nous) et en simplifiant à mort : les lambdas d'AWS c'est des bouts de code "exécutables" (un zip pour du javascript/typescript, un jar pour du java, pour lequel on précise une classe et une méthode comme point d'entrée) qui est sollicité par une "API gateway" qui expose des endpoints REST ou HTTP et redirige vers les lambdas justement.

    Du coup notre application n'est pas 1 livrable, mais plein de livrables qu'on redéploie à volonté très simplement.
    L'avantage des offres Cloud c'est qu'on paramètre la façon dont le scalling doit se comporter et ça gère la charge pour nous.
    Et surtout le coût : là où on payait un serveur disponible 24h/24 (sur AWS également) alors qu'il ne devait gérer que des appels très ponctuels, en se débarrassant du serveur on a divisé notre coût d'infra par 15 !

    Par contre cette solution n'est pas viable pour toutes les applications. La notre est sollicitée ponctuellement par des utilisateurs pour lesquels on n'a aucun besoin de session utilisateur donc c'est parfait.
    Et bien sur la grosse contrainte pour notre appli c'est qu'elle est totalement dépendante de AWS. Si on veut s'en débarrasser ca nous couterait beaucoup de travail (ce qui ne serait pas le cas si on avait choisi de conserver un serveur d'app).
    "Tout est vrai, tout existe, il suffit d'y croire."
    Dieu. (enfin… je crois)

  3. #4443
    Citation Envoyé par Kamasa Voir le message
    C'est effectivement ça. Sauf peut être pour le serveur qui tourne chez l'hébergeur Cloud, là j'ignore comment ils choisissent de gérer ça.
    Mais concrètement (pour nous) et en simplifiant à mort : les lambdas d'AWS c'est des bouts de code "exécutables" (un zip pour du javascript/typescript, un jar pour du java, pour lequel on précise une classe et une méthode comme point d'entrée) qui est sollicité par une "API gateway" qui expose des endpoints REST ou HTTP et redirige vers les lambdas justement.

    Du coup notre application n'est pas 1 livrable, mais plein de livrables qu'on redéploie à volonté très simplement.
    L'avantage des offres Cloud c'est qu'on paramètre la façon dont le scalling doit se comporter et ça gère la charge pour nous.
    Et surtout le coût : là où on payait un serveur disponible 24h/24 (sur AWS également) alors qu'il ne devait gérer que des appels très ponctuels, en se débarrassant du serveur on a divisé notre coût d'infra par 15 !

    Par contre cette solution n'est pas viable pour toutes les applications. La notre est sollicitée ponctuellement par des utilisateurs pour lesquels on n'a aucun besoin de session utilisateur donc c'est parfait.
    Et bien sur la grosse contrainte pour notre appli c'est qu'elle est totalement dépendante de AWS. Si on veut s'en débarrasser ca nous couterait beaucoup de travail (ce qui ne serait pas le cas si on avait choisi de conserver un serveur d'app).
    En gros, c'est la logique du micro-service poussé à l'extreme.

    A noter que Spring fournit un framework qui permet de déployer sur AWS ou Google Cloud de manière quasi-transparente, je crois.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  4. #4444
    Ok, donc tu mets ce que tu veux dans ton jar (donc éventuellement une appli springboot).
    Est-ce qu'AWS force l'utilisation d'API propriétaire pour le stockage des données (comme sur Google App Engine - ça fait des années que je ne regarde plus cette archi, c'était comme ça il y a une dizaine d'année)

  5. #4445
    Quand tu parles de mettre ce que tu veux dans un jar, si c'est le jar d'une lamda alors non, va pas mettre une appli Springboot.

    Ton Springboot embarque son serveur d'application qui va mettre son p'tit temps à démarrer et dont l'intérêt est de rester en vie.
    Les lambda AWS sont censées avoir une durée de vie très courte et surtout on s'attend à ce qu'elles puissent démarrer très rapidement (logique puisque si un endpoint n'est pas sollicité, il n'y a pas de lambda qui tourne derrière).

    Et là le raisonnement logique c'est de se dire "du Java qui démarre rapidement ? MER IL ET FOU !".
    Effectivement. On a bien quelques fonctions en Java qui démarrent en quelques secondes et on trouve ça bien trop long. Donc soit on construit nos Jar avec Quarkus et là on démarre nos jars en moins de 0.1 seconde, ce qui est cool soit on écrit nos fonctions en Typescript, beaucoup plus rapide à démarrer.

    Pour ce qui est du stockage de données, c'est toi qui voit.
    Soit tu l'externalise complètement et tu l'appelle via un appel HTTP classique mais là il sort du réseau privé. Soit tu le fait gérer par un service AWS (via le service RDS par exemple). Soit tu passes sur le service de stockage de AWS (DynamoDB, non-relationnel).

    En vrai, AWS ne te force l'utilisation d'aucun de leur service dédié. En fait si puisque tu passes par leur infra tu vas utiliser leurs services d'infra bien sur
    Mais si tu veux conserver une app SpringBoot, alors tu la déploie sur leur service EC2 qui est adapté. Tu veux conserver ta BDD ? Tu passes par RDS, mais en (très) gros ces services vont un peu faire passe-plat.
    "Tout est vrai, tout existe, il suffit d'y croire."
    Dieu. (enfin… je crois)

  6. #4446
    tu peux faire un spring boot non web et donc sans serveur d'appli, par exemple pour utiliser spring-data ou des services existant. Et ça démarre relativement vite un spring-boot dépouillé de la sécu et du web... (Bon ok c'est plus de 1 seconde)
    Après c'était purement théorique comme commentaire.

    Vous avez du coup des dizaines de petits modules tous indépendant les uns des autres ?

  7. #4447
    C'est ça, sur notre app principale on a un projet (géré par Maven) avec une vingtaine de modules, certains modules pondent plusieurs livrables.

    Après avec AWS il y a tout un plan de déploiement sur leur infra : CloudFormation. Soit on le renseigne à la main, soit on fait un snapshot d'un truc actuellement déployé (genre notre branche de dev), soit on le reconstruit avec CDK qui nous permet d'écrire "programmatiquement" notre stack de déploiement (ce qui est aussi très pratique).

    Le redéploiement complet c'est quand on repart de 0 sur une branche de dévelopment.
    Dans la pratique, tu fais des modifications sur une fonctionnalité, tu construit ton livrable, tu te rends sur AWS et tu redéploies juste le truc que tu viens de modifier en uploadant ton zip/jar. C'est quasiment du micro-service comme l'a fait remarque Teocali.
    "Tout est vrai, tout existe, il suffit d'y croire."
    Dieu. (enfin… je crois)

  8. #4448
    Citation Envoyé par William Vaurien Voir le message
    Ok, donc tu mets ce que tu veux dans ton jar (donc éventuellement une appli springboot).
    Je connais pas pour AWS, mais pour Google Cloud, ce n'est pas possible. Ta fonction doit être une classe Java qui hérite d'une certaine interface, et c'est la méthode de cette interface qui est appelée. Si tu voulais faire du Spring boot la dedans, faudrait greffer le cycle de vie de ton application Spring boot sur celui de la fonction (parce que tu n'as pas de réel controle sur celui de la fonction, juste la possibilité de l'interroger).
    Est-ce qu'AWS force l'utilisation d'API propriétaire pour le stockage des données (comme sur Google App Engine - ça fait des années que je ne regarde plus cette archi, c'était comme ça il y a une dizaine d'année)
    Je ne sais pas pour AWS, mais ce n'est pas le cas pour les fonctions google. Par contre, par défaut, elle n'ont pas accès a l'exterieure, faut que tu configures correctement ton projet GCP pour ça.
    Et ça n'a de toute façon aucune espèce d'interet : une Fonction google a pour but de pouvoir être démarrée et arrêtée de manière transparente.

    En gros, pour faire une comparaison avec Spring Boot, chaque function est grosso modo, soit une methode d'un de tes controller, soit un controller entier. c'est très restrictif, bien sur, mais l'idée est là. Tiens, ça devrait te parler : un helloworld en Google Function : https://github.com/GoogleCloudPlatfo...HelloHttp.java
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  9. #4449
    Oui, c'est une implémentation avec des limitations. Chez Azure (Azure Function) t'a une limitation de temps d’exécution, au delà le code est déchargé et ton appel perdu. L'intérêt principal de ces trucs là c'est la composabilité avec les autres produits clouds et les évènements proposés : un fichier viens d'être uploadé sur un AzureBlob ? Un évènement est automatiquement lancé qui exécute une AzureFunction qui va automatiquement faire du boulot dans une BDD cloud, etc.

  10. #4450
    Merci pour les explications, je comprend mieux le concept. Par contre ça doit vitre être pénible de gérer plein de petits modules s'ils sont interdépendant.
    J'ai l'impression que conceptuellement c'est un peu comme OSGI mais à beaucoup plus grande échelle ?
    Au niveau dev local comment ça se passe ? Il y a un 'émulateur' d'env AWS ou il faut déployer aussi sur le cloud ?

  11. #4451
    Citation Envoyé par William Vaurien Voir le message
    Merci pour les explications, je comprend mieux le concept. Par contre ça doit vitre être pénible de gérer plein de petits modules s'ils sont interdépendant.
    Comme dit, c'est "juste" du microservices poussé à l'extrème. Donc si tu es dans une équipe qui a deja résolu les soucis lié a ce genre d'architecture, ça va assez vite, je pense
    J'ai l'impression que conceptuellement c'est un peu comme OSGI mais à beaucoup plus grande échelle ?
    Aucune idée. le peu que j'ai vu de OSGI m'a absolument pas donné envie d'aller voir plus loin
    Au niveau dev local comment ça se passe ? Il y a un 'émulateur' d'env AWS ou il faut déployer aussi sur le cloud ?
    Je sais pas pour AWS, mais pour Google Functions, tu as un plugin gradle (et sans doute maven) qui te permet de lancer ta fonction en environnement local. Si c'est du HTTP trigger, t'as un simple server web qui dispatche ta requète a ton code. Si c'est un trigger plus compliqué, je sais pas
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  12. #4452
    OSGI c'est très mal expliqué mais ça permet d'ajouter/supprimer à chaud des "bundles" dans une jvm.
    Les bundles sont des jars, avec des services implémentant une interface spécifique.
    OSGI tient à jour une liste de tous les services qui sont installés et qui sont actifs dans la jvm pour pouvoir les connecter les uns aux autres.
    Je déteste Eclipse comme IDE mais c'est avec ça que marche (ou marchait dans le passé, je ne sais plus du tout si c'est toujours le cas) son système de plugins. (en fait d'après Wikipédia les 3 gros IDE java utilisent OSGI, ainsi qu'une pelleté d'autres gros produits)

    C'est en fait assez proche de la définition des Google Functions que j'ai lu plus haut, sauf que dans le cas de Google la jvm est remplacée par une infra cloud.

    J'avais utilisé OSGI pendant mes études pour faire du "java embarqué" (moquez-vous), pour pouvoir ajouter du comportement sur une jvm sans avoir à la redémarrer.

  13. #4453
    ouais, ok, non, rien a voir en fait.
    Deja, faut piger la logique de microservices : au lieu d'avoir une grosse application, t'en a une pelletachiée qui communique ensemble. Genre par exemple, au lieu d'avoir une seule application e-commerce qui gère ton site, t'as un micro-service "vitrine", un micro-service "panier" et un micro service "compte-utilisateur", chacun de ces services pouvant être une application Spring Boot par exemple. L'avantage est de pouvoir gérer les resources de manière beaucoup plus fine. Genre, si t'as besoin de 8 instances pour gérer le coté panier du truc, ben, tu montes 8 instances du micro-service "panier". Et t'es pas obligé de monter autant d'instance a coté.
    L'autre avantage, c'est que comme ces services sont généralement plus petit, ils sont plus réactifs lors des montée ou des descentes en demande.
    Par contre, ça oblige a prévoir toute une infrastructure logiciel : un discovery service pour que les nouveaux services puissent dire "je suis là, j'attends", un load balancer pour distribuer la charge, etc.

    Le serverless, ça pousse la logique jusqu'au bout : tu ne t'occupes que de ton code, le reste du bordel (load balancing, discovery,etc.) est géré par l'infrastructure de ton hebergeur de Cloud
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  14. #4454
    Oui l'idée de la scalabilité est assez centrale avec ces trucs, tu a un handler logique au cul d'un type d'évènement et t'a plus besoin de te préoccuper de combien il faut en mettre, du type de machines, comment le paralléliser, etc. Si t'a des variations énormes d'utilisation c'est très pratique.

  15. #4455
    Le principe des microservices ça va je comprend bien, et c'est quand même un concept assez ancien aujourd'hui. J'étais plus intrigue par les lamda AWS (là je voyais pas du tout de quoi il s'agissait).

    Il y a quand même une grosse analogie entre OSGI et ce qui m'a été décrit sur les lamdas AWS et les Google Functions. Il y a un gros changement d'échelle (avec en plus la gestion de la montée en charge) mais on retrouve bien l'idée du bundle avec sa petite fonction qui va être rajouté dynamiquement dans une infra qui contient déjà d'autres petites fonctions.

  16. #4456
    Citation Envoyé par William Vaurien Voir le message
    Le principe des microservices ça va je comprend bien, et c'est quand même un concept assez ancien aujourd'hui. J'étais plus intrigue par les lamda AWS (là je voyais pas du tout de quoi il s'agissait).

    Il y a quand même une grosse analogie entre OSGI et ce qui m'a été décrit sur les lamdas AWS et les Google Functions. Il y a un gros changement d'échelle (avec en plus la gestion de la montée en charge) mais on retrouve bien l'idée du bundle avec sa petite fonction qui va être rajouté dynamiquement dans une infra qui contient déjà d'autres petites fonctions.
    Mouais, ça peut se défendre.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  17. #4457
    Citation Envoyé par William Vaurien Voir le message
    Merci pour les explications, je comprend mieux le concept. Par contre ça doit vitre être pénible de gérer plein de petits modules s'ils sont interdépendant.
    J'ai l'impression que conceptuellement c'est un peu comme OSGI mais à beaucoup plus grande échelle ?
    Au niveau dev local comment ça se passe ? Il y a un 'émulateur' d'env AWS ou il faut déployer aussi sur le cloud ?
    Sur AWS, vu que tout ce qu'on déploie est accessible derrière une API Gateway, c'est ce service qui relie le tout et chaque développeur peut donc déployer sa propre stack derrière son API-Gateway-à-lui.
    Et vu que le gros intérêt du serverless est que ça ne coute rien quand ce n'est pas sollicité, alors on se créé plein de stacks pour nous
    Il existe un AWS-cli qui nous permet d'interfacer des lambdas qu'on fait tourner localement et qui sont "branchées" sur une API Gateway déployée, très pratique pour debugger par exemple.

    Concernant l'interdépendance, ce n'est pas vraiment le cas. Faut vraiment voir les lambdas comme des fonctions indépendantes (qui peuvent toutefois s'appeler les unes et les autres, mais on ne le fait pas trop)

    Et enfin, l'analogie avec OSGi n'est pas trop viable avec les Lambdas, par contre elle me parait plus pertinente avec l'ensemble d'une plate-forme comme AWS (à une autre échelle par contre)
    "Tout est vrai, tout existe, il suffit d'y croire."
    Dieu. (enfin… je crois)

  18. #4458
    Je ne trouve pas de topic réseau généraliste où poser cette question, alors je pose ça là vu que c'est surement là qu'il y a le plus de « gens qui savent », n’hésitez pas à me dire si on a un endroit plus approprié.

    Je me posais la question de la sécurité dans un réseau, je suis nul dans ce domaine et on a quelques questions qui émerge dans ma boite à ce propos en ce moment et j'ai parfois du mal à tout saisir.

    Par exemple, je ne comprends pas forcement super bien un concept pourtant assez simple : le filtrage de port. Ça pose pas mal de soucis applicatif là ou je suis et ça semble être une nécessité de sécurité. Pourtant j'ai un peu du mal à saisir en quoi, finalement, un filtrage de port augmente la sécurité. Déjà parce qu'il faut que quelqu'un écoute sur les ports en questions, donc on filtre en supposant qu'il y aurait un logiciel malveillant à l'écoute chez nous ?
    Et ensuite, même dans cette hypothèse, qu'est ce qui empêche le-dit logiciel malveillant d'emprunter un port ouvert très couramment (tout port en rapport avec le web ou autre).

    Bref, en somme, de l'exterieur d'un point de vue de non professionnel du domaine ça donne l'impression d'une mesure de protection un peu au pif... j'imagine que ce n'est pas vraiment le cas, comment expliqueriez vous ceci ?

  19. #4459
    Citation Envoyé par Nilsou Voir le message
    Je ne trouve pas de topic réseau généraliste où poser cette question, alors je pose ça là vu que c'est surement là qu'il y a le plus de « gens qui savent », n’hésitez pas à me dire si on a un endroit plus approprié.

    Je me posais la question de la sécurité dans un réseau, je suis nul dans ce domaine et on a quelques questions qui émerge dans ma boite à ce propos en ce moment et j'ai parfois du mal à tout saisir.

    Par exemple, je ne comprends pas forcement super bien un concept pourtant assez simple : le filtrage de port. Ça pose pas mal de soucis applicatif là ou je suis et ça semble être une nécessité de sécurité. Pourtant j'ai un peu du mal à saisir en quoi, finalement, un filtrage de port augmente la sécurité. Déjà parce qu'il faut que quelqu'un écoute sur les ports en questions, donc on filtre en supposant qu'il y aurait un logiciel malveillant à l'écoute chez nous ?
    Ou une fausse manip, ou un logiciel mal configuré, ou bugué, ou un truc innocent mais trop moderne avec une super feature d'auto update dont personne n'est au courant mais que des hackers pourraient connaître et utiliser pour profiter d'une faille. D'une manière générale, on peut considérer qu'une bonne sécurité c'est quand tu sais ce qu'il se passe précisément, et donc tout ce qui n'est pas censé être utile au bon fonctionnement du système doit être bridé.

    Citation Envoyé par Nilsou Voir le message
    Et ensuite, même dans cette hypothèse, qu'est ce qui empêche le-dit logiciel malveillant d'emprunter un port ouvert très couramment (tout port en rapport avec le web ou autre).

    Bref, en somme, de l'exterieur d'un point de vue de non professionnel du domaine ça donne l'impression d'une mesure de protection un peu au pif... j'imagine que ce n'est pas vraiment le cas, comment expliqueriez vous ceci ?
    Rien ne l’empêche, à priori. Et en particulier maintenant qu'à peu près tout passe par du http(s) bah ça devient un peu inutile de filtrer les autres ports. C'est pour ça qu'ensuite tu vas souvent avoir des filtres supplémentaires plus haut niveau, avec par exemple analyse des ips ou même des entêtes et du contenu http(s) - oui, y compris sur du https, dans certaines boites tu vas avoir un certificat racine de la boite installé sur les ordis pour permettre au firewall de déchiffrer et rechiffrer le traffic, pour faire du check antivirus et cie, sans avoir d'avertissement de sécurité sur le navigateur.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  20. #4460
    Ton raisonnement est globalement correct Nilsou, mais ça reste une protection potentiellement utile:

    Déjà faut voir de quel sens on parle, filtrage entrant ou sortant.

    Dans le cas du filtrage entrant tu vois bien que ça t'économises de recevoir du traffic polluant pour rien. Plutôt que de recevoir une tentative d'accès (extérieure) SSH sur port 22, bah tu la drop/discard direct.

    Sinon comme l'a dit le canard ci dessus ça reste une première mesure "gratuite" qui peut parfois te sauver à moindre coût, autant le faire, une espèce de parachute de secours ou de ceinture, d'airbag, tu veux jamais te reposer dessus, mais ça peut s'avérer utile. S'comme dire pourquoi j'ai besoin d'un airbag, suffit de bien conduire.

    Imaginons un sous réseau qui accepte du traffic externe (ton pc chez toi par exemple, il accepte du traffic externe, pareil pour la console de jeu), dans le sous réseau t'as des appareils qui communiquent entre eux sur le port XXXX. Ca t'évites de recevoir du traffic externe qui tenterait de controler tes devices à distance.

    Bien sûr au niveau du device tu pourrais implémenter la protection, mais pourquoi ne pas déléguer ça à un composant supérieur et dormir tranquille. Et éviter qu'un petit malin imprime sur ton imprimante ou commande 40 café fraises sur la machine à café connectée.

    Surtout que si c'est une imprimante connectée achetée pas cher, bah tu peux pas modifier le firmware, donc comment tu évites qu'un guignol la contrôle à distance?

    Ton imprimante tout ce qu'elle attend c'est qu'un paquet réseau lui arrive dans le nez avec une IP source et sur le port approprié. Elle a aucun contexte de où elle se situe en terme de sous réseau et d'où provient le traffic, elle reçoit des instructions et point barre.

    ---

    Alors bien évidemment mes exemples sont un peu exagérés, tu pourrais simplement mettre les devices à risque dans un sous réseau dédié (sous sous réseau donc), inaccessible de l'extérieur, drop tout traffic extérieur, ou provenant d'ip non reconnues (mais du coup faut gérer l'ip spoofing, surtout en ipv4), etc. C'est le job du firewall, et tu peux arriver à un niveau de sophistication très élevé.

    Mais plutôt que de trop réfléchir, tu peux dire, bon je dégage tout ce qui ne fait pas partie des ports que je veux supporter, au moins c'est fait.

    C'est effectivement une mesure de sécurité assez faible, et y'a de nombreuses failles à exploiter si c'est ta seule protection, mais c'est un premier pas.

  21. #4461
    Un exemple typique, qui effectivement est un peu naze c'est quand une boite bloque du traffic sortant, et c'est peut-être l'exemple que tu avais en tête (edit: ah non tu parles d'entrant, donc l'exemple ci dessus).

    Genre imaginons que ma boite m'empêche de faire du SSH vers l'extérieur, ou du HTTP (80). Je peux effectivement contourner ça en un clic en me connectant via n'importe quel autre protocole/port dispo à une machine distante et je demande à la machine distante de s'occuper de mon business, un tunnel donc (on peut aussi dire proxy, même idée, c'est un tunnel logique fourni par une machine distance "le proxy").

  22. #4462
    Ok. Je comprends votre raisonnement.

    Moi mon soucis ici c'est que je suis contraint dans pas mal de domaine ou je bosse localement d'utiliser des logiciels qui s'en remettent à des ports aléatoires. Dans les deux sens. (ROS typiquement)
    Du coups j'aurais bien aimé que les autres sous réseau de la boite puisse communiquer avec celui-ci sur tout les ports et puisse envoyer du trafic entrant à tout les PC de la boite sur n'importe quel port.

    Sauf que non gnagnagna « tu imagines si quelqu'un hack ton robot mal protégé là, surtout que tu as plein d’élève qui vont y accéder en root, alors il pourrait tenter de hacker les PC des autres etc. » . Je trouve que ça confine un brin à la paranoïa ...

    Bon et accessoirement c'est bloquant pour moi. On me propose de mettre des VM sur le même sous réseau, mais comme c'est franchement pas l'objectif de l'enseignement c'est n'imp ...

  23. #4463
    Disons que ça fait partie de la stratégie de défense en profondeur : chaque couche de protection est loin d'être suffisante en soit mais c'est l'accumulation des différentes couches qui permet d'avoir une bonne sécurité (surtout contre des types d'attaque très variés).
    C'est la faute à Arteis

  24. #4464
    Ok je découvre. Je pensais que la sécurité c'était quand même moins du gruyère

    C'est quand même particulier finalement de se dire qu'on ne peut pas profiter pleinement d'une technologie de communication sur un parc de PC en local par peur des attaquants externes ...

  25. #4465
    Ben après, le filtrage au sein du réseau local c'est pas directement contre les attaques externes, plus pour éviter la propagation de celles-ci.
    Et les attaques internes ça existe aussi.
    C'est la faute à Arteis

  26. #4466
    Oui, ils ont peur que des personnes usant du matériel puissent accéder à d'autres PC.

    La sécurité, c'est un monde de merde, je vous le dit !

  27. #4467
    Pouah j'ai enfin commencé à toucher aux concept en c++20 (oui je suis en retard). Enfin ce besoin de base est pourvu! Les compilateurs récents ont le support.

    On avait besoin de ça depuis tellement longtemps.

    Bon je découvre tout juste donc y'a encore plein de trucs et de bonnes pratiques qu'il faut que j'apprenne, mais ça me sert déjà beaucoup.

    Enfin un moyen hyper simple de faire des interfaces pour les templates, faut que je me trouve une bonne doc sur le sujet pour voir tous les trucs cool qu'on peut faire.

    Voilà un exemple hyper basique

    Code:
    template<class T>
    concept Clock = requires(T clock) {
        { clock.test() } -> std::convertible_to<bool>;
        clock.start();
        clock.stop();
        clock.get_time();
    };
    
    template<class T> requires Clock<T>
    class ClockConsumer {
    };
    
    class ClockInstance {
      public:
        static bool test() { return true; };
        void start() { };
        void stop() { };
        void get_time() { };
    };
    
    int main() {
        ClockConsumer<ClockInstance> clock_consumer;
        return 0;
    }
    D'autres exemples plus pertinents ici: https://en.cppreference.com/w/cpp/language/constraints
    Dernière modification par Kamikaze ; 10/12/2021 à 11h36.

  28. #4468
    Comment ça ? Tu ne le faisais pas déjà en C++17 ?

    Sinon, oui les concepts c'est bien : plus simple à écrire, plus simple à lire, plus simple à compiler, plus simple à débugguer.
    Dernière modification par Cwningen ; 10/12/2021 à 16h37.

  29. #4469
    Mais quelle horreur

  30. #4470
    Ça a l'air sympa, c'est fait à la compilation la vérification c'est ça ?
    Je suis pas super convaincu par le vocabulaire utilisé par contre. « Constraint » et autres « require » ça va, mais « concept » on sent qu'ils étaient en panne d'inspiration quand même ( et je vois pas le lien avec ce que ça fait : proposer une liste de prérequis pour autoriser la compilation)

Page 149 sur 154 PremièrePremière ... 4999139141142143144145146147148149150151152153154 DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •