Programmer des services web (ou n'importe quel middleware) est pénible et inutile dans la plupart des cas, alors que Linux propose de quoi faire communiquer des programmes en lisant simplement des fichiers.
Cette dépêche vous montre comment.
Sommaire
Introduction
Justification
Le problème consistant à faire communiquer deux programmes est l'un de ceux qui ont généré la plus grande littérature et le plus grand code de toute l'informatique (avec l'invalidation de cache, nommer des choses et les frameworks Web).
Face à un tel problème, un programmeur pense immédiatement « je vais utiliser un middleware ». Si vous ne savez pas vraiment ce qu'est un middleware, rassurez-vous, personne ne le sait vraiment. Aujourd'hui, vous avez peut-être entendu parler de leur dernier avatar : les services web. Comme notre programmeur va s'en rendre compte, on a maintenant deux problèmes. La charge d'écriture, d'utilisation et de maintenance du code utilisant des middlewares est toujours énorme.
Parce qu'ils sont conçus pour gérer un très grand nombre de fonctionnalités et de situations complexes - la plupart d'entre elles impliquant des utilisateurs adverses, des utilisateurs robots, ou les deux.
Mais la plupart du temps, le problème réel n'implique pas vraiment ces situations. Du moins pas au début (… ce qui signifie probablement jamais). Les personnes connaissant l'histoire des middlewares diront que leur caractéristique principale n'est pas seulement le passage de messages, mais aussi l'appel à distance, qui implique la sérialisation des objets. Mais la plupart du temps, les messages sont assez simples de toute façon, et utiliser un middleware pour implémenter la sérialisation d'une liste d'instances ayant trois membres de types fondamentaux n'est pas une bonne utilisation de votre temps.
Si vous construisez des (premières versions de) programmes communicants qui fonctionneront sur un réseau local (sûr), et pour lesquels les messages échangés sont connus et simples, alors j'ai une bonne nouvelle : vous n'avez pas besoin d'utiliser des services web (ou tout autre type de middleware).
VOUS DEVEZ JUSTE SAVOIR COMMENT LIRE/ÉCRIRE DEPUIS/VERS DES FICHIERS (SPÉCIAUX).
Vue d'ensemble
L'idée de base est qu'au lieu de programmer l'interface réseau de votre service avec des sockets de bas niveau ou toute autre bibliothèque de haut niveau, vous pouvez simplement mettre en œuvre des mécanismes de requête/réponse en utilisant des tubes nommés.
Les tubes nommés sont des fichiers spéciaux FIFO (First In, First Out) qui bloquent les E/S et mettent en œuvre une forme très basique de passage de messages, sans avoir à s'embarrasser avec le polling. De plus, ils sont très faciles à utiliser, puisqu'il s'agit simplement de fichiers dans lesquels vous lisez/écrivez.
Une fois que vous avez créé votre service au-dessus de ces tubes, il est facile de l'intégrer dans une interface réalisée avec d'autres langages/outils. Par exemple, il est très facile de l'exposer sur le réseau en utilisant des outils courants comme socat.
Attention, ce n'est pas sécurisé, vous ne devez l'utiliser qu'à des fins de test dans un réseau local sûr.
Principe
Le principe théorique peut être représenté par ce diagramme de séquence UML :
Tubes nommés
┌────────┴────────┐
┌──────┐ ┌──────┐ ┌──────┐ ┌───────┐
│Client│ │SORTIE│ │ENTRÉE│ │Service│
└───┬──┘ └─┬────┘ └────┬─┘ └───┬───┘
│ │ │ │
│ │ │┌───────╢
│ │ bloque││attente║
│requête │ │└──────→║
├─────────────────────→│ │
╟───────┐│ ├───────→│
║attente││bloque │ ║traitement
║←──────┘│ │ ║
│ │←─────────────────────┤
│←───────┤ │ réponse│
│ │ │ │
Notes :
- Le service est démarré en premier et attend l'entrée, mais comme les processus sont bloquants, l'ordre de démarrage n'a pas toujours d'importance.
- Il y a deux tuyaux, ici (un pour l'entrée et un pour la sortie), pour des raisons de simplicité, mais vous pouvez tout aussi bien n'en utiliser qu'un seul.
Exemples
Pour créer les tuyaux nommés sous Linux ou MacOS, utilisez la commande mkfifo, comme indiqué dans le script build.sh.
La création de tuyaux nommés sous Windows est plus complexe, vous pouvez consulter la question Stack Overflow correspondante.
Exemple trivial : un service de chat
L'exécutable pcat implémente un service qui lit depuis un tuyau nommé et imprime son contenu sur la sortie standard. C'est comme une commande cat, mais qui ne s'arrêterait pas après la première lecture, mais continuerait à lire depuis le tube.
Ce type de service est juste une simple boucle qui itère sur les appels d'E/S bloquants sur les tuyaux nommés, ayant ainsi un coût CPU nul pour l'interrogation.
Remarque : si cet exemple imprime « Hello World ! » en continu, c'est parce que vous n'avez pas créé le fichier de données comme un tube nommé, mais comme un fichier normal. Par conséquent, au lieu de vider son contenu après la lecture, il continue à lire le même contenu.
#!/usr/bin/env python
import sys
if __name__ == "__main__":
while True:
with open(sys.argv[1]) as fin:
line = fin.readline()
sys.stdout.write(line)Un service simple
Le premier exemple ./service in out implémente un service qui lit depuis un tuyau nommé in et écrit vers un autre tuyau out.
Une fois lancé, le service va attendre que les tuyaux soient consommés, par exemple avec deux commandes. La première écrit une entrée dans le tuyau d'entrée :
echo "données" > inLe second lit le résultat :
cat outNotez que vous pouvez utiliser le même tuyau pour l'entrée et la sortie
: ./service1 data data.
#!/usr/bin/env python
import sys
if __name__ == "__main__":
print("Start server")
while True:
with open(sys.argv[1]) as fin:
datas = fin.readline()
data = datas.strip()
print("Received: <",data,">", file=sys.stderr)
with open(sys.argv[2], 'w') as fout:
fout.write(data)
if data == "exit":
break
print("Stop server", file=sys.stderr)Exposer ces services sur le réseau
Si vous souhaitez exposer un tel service en tant que serveur réseau, utilisez simplement socat.
Par exemple, pour obtenir une requête de données du réseau pour le service1:
socat -v -u TCP-LISTEN:8423,reuseaddr PIPE :./data(voir run_socat_server.sh pour un exemple complet).
Vous pouvez le tester en envoyant quelque chose sur la connexion :
echo "Hello World !" > /dev/tcp/127.0.0.1/8423Inversement, pour renvoyer automatiquement la réponse à un serveur :
socat -v -u PIPE :./out TCP2:8424:hostSachez que socat se termine dès qu'il reçoit la fin du message.
Ainsi, si vous souhaitez établir un portail permanent, vous devrez utiliser l'option fork:
socat TCP-LISTEN:8478,reuseaddr,fork PIPE:/./dataAller plus loin
- Plus d'exemples en Python et C++ (143 clics)
# Réseau local sûr
Posté par zyphos . Évalué à 10.
Je pense que plus aucun réseau local n'est sûr.
Vu le nombre d'objets connectés et smartphone sans mise à jour disponible, il faut partir du principe que le réseau local n'est pas sûr malheureusement.
Même en utilisant des pares-feux, on n'est pas à l'abri d'une adresse IP spoofé.
Personnellement, je n'utiliserai les Named Pipes que pour des processus au sein d'une même machine.
[^] # Re: Réseau local sûr
Posté par Wendigogo . Évalué à 2.
Je partage cet avis.
Mais n'est-il pas possible d'utiliser ces tubes nommées dans un protocole de communication sécurisé (type SSH) ? On pourrait aussi envisager de chiffrer les données avant envoi (dans le tube nommé) non ?
Ça impose de connaitre/imposer les 2 machines qui communiquent (sur un réseau local ça ne me parait pas trop contraignant) mais ça permet d'ajouter une couche de sécurité à faible frais.
Attention, je n'ai aucune compétence dans ce domaine. Seulement quelques notions de base donc peut-être que ces propositions ne sont pas applicables/sont inutiles.
D'ailleurs, en partant de ce principe (réseau local non sûr), quel est l'avantage des "web services/middlewares" ici ?
[^] # Re: Réseau local sûr
Posté par Yth (Mastodon) . Évalué à 10.
Tu peux chiffrer la communication avec un outil comme stunnel.
C'est un bête tunnel SSL/TLS, ta socket locale se connecte localement à stunnel en clair, stunnel local se connecte à stunnel distant en chiffré, et stunnel distant se connecte à ta socket distante localement, en clair.
Et hop, rien ne circule en clair sur le réseau :)
Ça peut servir à faire du mySQL distant, chiffré, sans ouvrir mySQL sur le réseau par exemple.
[^] # Re: Réseau local sûr
Posté par dudule42 . Évalué à 10.
Exact.
Pour résoudre ce problème socat(1) sait faire du TLS pour chiffrer la communication.
J'ai même travaillé sur un patch de socat pour faire de l'authentification du client par le serveur avec une carte à puce (ou tout autre token PKCS#11). C'est sur mon blog "PKCS#11 support in socat"
# « tubes nommés » ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
Vraie question : est-ce que vous utilisez concrètement le terme « tubes nommés » ?
Depuis que je fais de l’informatique, j’ai toujours entendu le nom anglais de [named] pipe pour désigner ce concept. Conséquence, j’ai eu du mal à comprendre ce dont pouvait bien parler cette dépêche, pourtant très intéressante.
La connaissance libre : https://zestedesavoir.com
[^] # Re: « tubes nommés » ?
Posté par cg . Évalué à 4.
Je connais l'expression "tube nommé" mais je dis surtout fifo. Le comble, je crois que je dis aussi pipe nommé de temps en temps (en prononçant paillepeu), quelle horreur ;). Mais jamais tube (nommé ou non).
[^] # Re: « tubes nommés » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Proposition de traduction : les noms d'une pipe !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Broker de messages
Posté par Mimoza . Évalué à 10.
Bon l’explication donné sur les middleware (logiciel du milieu ?) est un peu orienté et trop simpliste a mon goût.
Pour défendre un peu ces logiciels du milieu ce sont les gestionnaires de messages que ont la cote en ce moment, et a juste titre. Ils essayent de fiabiliser fortement pas mal de problématique que pose la transmission par réseaux.
Par exemple :
- S’assurer de la bonne réception du message, sinon le mettre en attente et le rejouer)
- Ne pas avoir un plat de spaghetti
- Simplification d’ouverture des flux
- Plein de type de connecteur (évite que chaque soft le fasse a sa sauce la transmission)
- Monitoring centralisé et harmonisé
- Gestion du multi émetteur/récepteur
- Gestion des abonnements (l’émetteur ne sait pas forcément qui consomme ses messages)
- et plein d’autre …
Bref pas mal de problématiques que l’on rencontre dans un SI un poil développé. Alors oui ça peu vite devenir une usine à gaz, si tu ajoute la mode des micro services ça devient vite ingérable. Mais ça fait du taff pour pas mal de monde :-
En ce moment c’est Kafka qui tient le haut du pavé, développé par LinkedIn.
[^] # Re: Broker de messages
Posté par Mathias Bavay (site web personnel) . Évalué à 2.
Est ce que je peux me permettre une question de béotien?
Dans mon domaine (la prévention du risque d'avalanches), j'ai l'habitude de faire tourner mon modèle de manteau neigeux avec des données de stations météo que je vais chercher dans une base de données. On est en train de changer la base de données (pour se débarrasser d'Oracle, j'applaudis des deux mains) et au passage de remettre à plat l'architecture. On me parle de lire et écrire les données via un middleware (RabbitMQ) au lieux d'une connexion directe à la base. En terme de volume, cela va de quelques ko à 50 Mo au maximum. Mais j'ai furieusement l'impression que ce n'est pas vraiment adapté à l'usage que je devrai en faire. Est ce que c'est parce que je n'ai rien compris ou bien est ce que mon sentiment diffus n'est pas si faux?
[^] # Re: Broker de messages
Posté par Mimoza . Évalué à 4.
«Il n'y a pas de question idiote, seulement une réponse idiote»
Réponse courte : Passe à PostgreSQL en plus du broker
Réponse longue : Pour commencer, les broker de messages ne sont pas fait pour traiter des messages de grosse taille. Par exemple par défaut Kafka est configuré pour des messages de 1Mo maximum. En clair ils transportent des lettres, pas des colis. Pour contourner cette problématique tu peux juste avoir un pointeur vers un stockage de masse.
Ensuite le broker n'est pas là pour stoker les messages, seulement les faire transiter. Il peux les stoker temporairement sur disque au cas ou ton système crash et que tu veuilles absolument ne pas perdre aucun message. Il faut le voir comme un postier, il fait le lien entre l'expéditeur et le destinataire, ni plus ni moins.
Les broker sont adapté pour des système «réactif», donc qui vont réagir à des évènements que l'on va leur transmettre, donc très unidirectionnel. L'expéditeur du message n'attend pas de réponse, si ce n'est celle du broker qui lui dit qu'il a bien pris en charge le message, pas plus.
Donc pour «lire» des données ce n'est pas terrible. Au mieux tu vas emmètre un message pour qu'un autre système émettent un autre messages qui contiendra les données (ou un pointeur) vers ce que tu souhaites. Du point de vu du broker, il n'a fait que transiter des messages. Mais je ne te conseillerais pas ce genre de fonctionnement. Si tu as des données a lire autant aller les chercher directement à la sources.
De ce que je comprend ton modèle travail sur des données collecté sur un temps certain, pas en «live». Donc pour ton archi je verrais bien quelque chose comme ça :
Bien sûr tu peux avoir plein de sources de données différentes qui pointent toutes vers le broker.
Bon c'est une analyse sur 2 lignes d'explications ;-)
[^] # Re: Broker de messages
Posté par Mathias Bavay (site web personnel) . Évalué à 1.
Merci pour la réponse, cela me confirme dans mon ressenti: c'est fait pour déclencher des actions, pas pour transporter des masses de données. La base de données est migrée vers PostgresSQL mais l'équipe en charge de la base voulait me convaincre d'utiliser RabbitMQ pour lire/écrire les données, ce qui me semblait peu approprié, je préfère effectivement aller chercher les données à la source!
Merci encore pour ton feedback!
[^] # Re: Broker de messages
Posté par barmic 🦦 . Évalué à 2.
RabbitMQ en particulier ne touche par défaut pas au disque, les messages de 50Mio tout en mémoire ça peut devenir très consommateur.
Le principe broker de message + db pour le volume est assez classique ça n'est pas quelque chose de particulièrement alambiqué.
Ah et ça n'a rien à voir, mais si tu utilise rabbitmq activer le plugin manager (dispo de base) aide beaucoup à s'y retrouver avec une interface pour comprendre et administrer le tout.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Broker de messages
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Je plussoies : Venant d'Oracle, la migration sera plus rapide (s'il y a du code avec du SQL non ANSI/standard…) et simple (en particulier s'il y a du PL/SQL dans la boucle) en passant à PostgreSQL !
Pour le broker, c'est effectivement pour de petits « messages » et non pour lire jusqu'à 50 MiO de données. J'ai l'impression que les devs et archis ont voulu se faire plaisir avec des technos sexy mais qui ne collent pas forcément au besoin.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Broker de messages
Posté par Dring . Évalué à 2.
Une architecture possible c'est :
J'ai pas encore de bonne vision de Kafka, mais j'ai cru comprendre qu'une gestion fine des permissions pouvait être un peu complexe, là où les APIs s'appuient sur le mécanisme "naturel" des applications. D'où l'intérêt de ne pas publier trop de trucs. Le défaut, c'est que potentiellement, avec cette approche, si le consommateur prend trop de temps à aller chercher les données, il peut rater des états intermédiaires.
Evidemment, si on envoie aussi l'état intermédiaire dans le message, et que l'application source garde tous les états, c'est pas grave, mais c'est le type de situation où il est préférable d'envoyer plus de données dans l'évènement.
En entreprise, ce que j'ai souvent vu, c'est du MQ (donc du message point à point) où on balance l'ensemble des informations nécessaire pour le destinataire. C'est pas très beau d'un point de vue architecture, mais ça marche, et l'infra est adaptée pour supporter des gros volumes de gros messages. Moins de contraintes pour l'émetteur. Du vrai couplage faible.
# Mouai
Posté par PR . Évalué à 10. Dernière modification le 01 septembre 2022 à 09:17.
Les pipes sont unidirectionnels. Autant utiliser des sockets UNIX si on veut émettre et recevoir entre processus. Et autant utiliser des sockets réseau si on veut faire communiquer deux machines.
Que ce soient pipe, anonyme ou nommé, ou socket, UNIX ou réseau, ça reste très basiquement des fichiers qu’on lit ou on écrit. Ça se voit pas forcément sur un langage type Python, mais en C on se retrouve dans tous les cas avec un file descriptor qu’on peut passer aux commandes read & write.
Voilà c’est cool de faire une dépêche sur les pipes. Mais là le cas d’usage est celui qui justifie d’utiliser du socket (UNIX ou réseau).
À la limite, le cas présenté relève de la petite astuce pour transformer un programme qui communique localement en un programme qui communique à travers le réseau.
Mort aux cons !
[^] # Re: Mouai
Posté par freem . Évalué à 3.
D'autant que l'on peut faire des sockets nommés, ce qui est assez pratique par exemple avec un tas de machines qui établissent un tunnel inversé sur un serveur qui permets de rebondir (bon, évidemment, une vraie architecture réseau serait plus efficace, mais on n'a pas tous le temps et les compétences pour ça, d'où l'usage de bouts de ficelles et de scotch parfois)
# Si je puis me permettre ...
Posté par Christophe B. (site web personnel) . Évalué à 10.
Bonjour à tous,
Attention je vais provoquer grave, vous pouvez moinssez : même pas peur
Les tubes nommés ou fichiers fifos existent depuis très longtemps, peut être même depuis les débuts d'unix (si quelqu'un à le courage de rechercher …)
Au siècle dernier cela servait a beaucoup de choses, comme par exemple le multiplexage de connexion série, la compression d'export oracle en shell ( que même chez oracle ils y avaient pas pensé …) , pour temporiser l'envoi de SMS via modem (je sais c'est plus tard …)
Puis est venu internet et le HTML, depuis tout le monde s'est mis à faire du Markup Langage
vu le succés du HTML difficile de le critiquer et pourtant …
Et on a oublié de refléchir tout devait passer par un langage de MARKUP
Quand on regarde comment cela fonctionne sous le capot, bien souvent il y a plus de contenant que de contenu ( les balises sont plus importantes que les données en volume …)
Les Web services n'échappent pas a cette régle et même si cela permet d'échanger des flux de données et de publier des fonctions, je n'ai jamais trouvé cette solution élégante
Surtout que très souvent un échange de fichier format CSV suffirait :)
J'ai vu trop souvent des canons de 105mm destiné à tuer des mouches dans les webs services (dans l'informatique de gestion celle que je connais) et des ressources informatiques inutilement dilapidées. Et beaucoup trop de dev ne jamais se poser de questions, surtout a ce sujet qui apparait comme une boite noire magique pour certains
Les tubes nommées et autres fifo par contre j'ai toujours trouvé cela élégant, ne consomme pas beaucoup de ressources pris en charge par le noyau et bien souvent très efficace
Content que cela refasse surface :)
C'est simple efficace élégant
Merci pour la commande socat je ne la connaissais pas.
[^] # Re: Si je puis me permettre ...
Posté par Dring . Évalué à 5. Dernière modification le 01 septembre 2022 à 17:36.
Ben déjà, les webservices suivent une route intéressante. De SOAP et les monstres qui allaient avec (l'artillerie XML et le WSDL de description), on migre progressivement vers REST/JSON.
Ca reste de l'artillerie lourde, mais passer par HTTP permet de profiter de plein de bonnes choses. Et notamment :
- oauth2 pour sécuriser les canaux.
- une simplification des règles firewall puisque tout passe par le port 443 sans pour autant sacrifier à la sécurité (cf. oauth2)
- une grammaire standard (PUT, GET, POST, DELETE, …)
- des fonctionnalités intégrées (le choix du format de réponse quand le serveur le supporte, la description de l'encodage et du format retourné, …)
Ca reste trop complexe, mais comme dit plus haut, on n'est plus dans un monde de bisounours où on peut faire confiance à une machine juste parce qu'elle est dans le même réseau, ou à un même process juste parce qu'il est sur la même machine.
A propos du format de réponse, le grand classique c'est JSON, mais avec un service REST rien n'empêche de faire du XML (pour les nostalgiques), du CSV, du fixed-length, du Excel, du PDF, du OpenDocument, …
[^] # Re: Si je puis me permettre ...
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6.
… ou même du gRPC pour les cas qui s’y prêtent, en particulier quand JSON/XML deviennent « trop lents et verbeux ».
La connaissance libre : https://zestedesavoir.com
[^] # Re: Si je puis me permettre ...
Posté par Dring . Évalué à 5.
Toutafé ; et de toute façon, si on a des contraintes de temps réel ou pseudo temps réel, la latence induite par HTTP n'est juste pas acceptable.
A problème différent, solution différente.
[^] # Re: Si je puis me permettre ...
Posté par Christophe B. (site web personnel) . Évalué à 5.
Comme tu le dis cela reste de l'artillerie lourde … pour un problème relativement simple : échanger des données
de SOAP WSDL - XML à REST - JSON cela évolue dans le bon sens, et il faut bien le reconnaitre cela fonctionne ( oauth2 est quand même un peu usine à gaz … )
Mais je ne peu pas m’empêcher de regarder des protocoles anté diluviens comme PeSit (90% des échanges interbancaires je crois) et de voir la simplicité et l'élégance de la chose.
pour résoudre le même problème.
La différence : les ressources humaines et financières misent en face du problème à l'époque
trop souvent on préférè acquérir un produit cela évite de réfléchir
Après on se retrouve devant des usines à gaz que plus personnes ne veut ou ne peut administrer
D'ailleurs ce que tu dis c'est triste :
[^] # Re: Si je puis me permettre ...
Posté par Dring . Évalué à 5.
100% d'accord sur oauth2. J'ai l'impression qu'on attend encore "la" solution qui permettra de faire tout ça plus simplement.
Pour les échanges interbancaires, c'est un domaine que je connais bien, et j'ai jamais entendu parler de PeSit. Une recherche sur internet semble faire un lien avec Axway CFT, qui est très utilisé en effet, mais est hautement merdique (je connais plusieurs centaines de personnes prêtes à tuer pour s'en affranchir).
De mon côté, les "protocoles" que je connais le mieux :
- SWIFT ; à la fois un réseau, un protocole, et une plateforme. Dans sa dernière mouture, c'est du XML, très, très, très chiant à manipuler. Plutôt orienté backoffice.
- FIX, un protocole et un format. Plutôt compact et efficace, orienté temps réel car utilisé pour le frontoffice/trading.
- CFT, SFTP et MQ (avec une ligne louée dédiée pour les communications vers l'extérieur), avec en général du CSV, du XML ou du texte à taille fixe
- Et les bons vieux formats type ETEBAC, qui sont pas trop interbancaires, mais plus pour des PME "non-orienté finance" pour générer des virements. Pendant longtemps, ça allait aussi avec une solution de télématique - mais j'ai pas touché à ça depuis 25 ans. Peut-être que c'est là que PeSit est utilisé ?
[^] # Re: Si je puis me permettre ...
Posté par Christophe B. (site web personnel) . Évalué à 10.
Ah ah … cela me m'étonne pas
Je le pratique depuis longtemps et j'ai eu la chance de travailler avec des personnes qui ne faisait que "ça" … et m'ont montré comment bien faire, pour donner un ordre de grandeur nous échangions avec une douzaine de "partenaires" au plus fort de l'utilisation … eux en géraient à peu près 300.
CFT à l'origine (avant que cela devienne Axway CFT …) est un produit simple robuste et sécure.
Les échanges bien qu'effectués à travers TRANSPAC pouvaient déjà être crypté et certains l'étaient : double sécurité donc
A cela tu rajoutes la reconnaissance des "partenaires" et cela pouvait se faire de plusieurs manières y compris via un protocole d'échanges de mot de passe, et ce a plusieurs niveaux.
Puis transpac a disparu … (encore un bel outil jeté à la poubelle …) et fallait passer par INTERNET et la on a vu la différence des partenaires :
Dans le cas numéro 1 : il a suffit de déclarer les adresses IP de n'autoriser que celle qui nous intéressent de se mettre d'accord sur un port de communication et cela roule.
Les produits comme CFT ont des dizaines d'années d'historique sur de multiples OS et configuration et vu l'importance des contenus ont toujours été tres suivi d'un point de vue sécuritaire … en gros rien à craindre même en passant via le net
les échanges de mot de passe et autres se faisait par téléphone généralement.
Dans le cas numéro 2 :
La on rigole … il a fallu rajouter des VPNS, des certificats (des vrais … payants !), des doubles authentifications et autres surcouches … à une couche déjà TRES sécurisé.
En gros ils n'ont rien compris et n'ont fait qu'appliquer les recettes utilisées ailleurs sans même se poser de questions.
Si la dessus tu rajoutes, le turn over habituel des grosses structures avec, bien entendu, AUCUN passage d'informations … tu te marres de les voir s'agiter dans leur fange … enfin presque parce qu'au début c'est OBLIGATOIREMENT de ta faute, toi le petit fournisseur externe
Donc oui je penses que certains doivent détester Axway CFT … parce qu'il ne le connaissent pas
Et désolé de vous parler comme un vieux con, mais cela va pas en s'arrangeant
Bon avant c'était pas mieux mais pas pour des raisons ubuesque comme celles ci
HTML n'était pas fait pour faire de la sécurité, ni pour gérer des sessions , Windows et le DOS n'aurait jamais du être aussi répandu sur les postes de travail, CFT et certains logiciels se passeraient bien de surcouche "sécuritaire" et de certificats décernés par par des "AUTORITE DE CONFIANCE" à obsolescence programmée etc …
C'est tout sauf de la logique , j'appellerai plutôt cela marcher sur la tête … vivement que le bon sens revienne et reste à définir (je n'ai pas la solution juste le gout de la critique … c'est plus facile :) )
Et je comprends pourquoi les extra terrestres ne nous contactent pas :) doivent se marrer quand même
[^] # Re: Si je puis me permettre ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
À propos de format, c'est encore utilisé EDI ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Si je puis me permettre ...
Posté par barmic 🦦 . Évalué à 2.
Je vois pas en quoi. Par exemple j'ai déjà fais du REST avec authentification TLS du client pour transmettre du protobuf. HTTP c'est un adressage (le verbe + le chemin) et des entêtes. TLS et sa négociation ou TCP avec entre autre sa gestion des congestions font déjà peut être plus de bruit.
HTTP est un protocole vraiment simple. Tout ce qui est complexe est en optin. C'est toi qui choisi de transmettre du XML, d'utiliser OAuth, d'avoir une websocket, etc.
Note qu'utiliser une socket unix ou un pipe (nommé ou non) ne change pas la question de l'encodage de ce que tu transmet (XML, JSON, messagepack, avro,…).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Si je puis me permettre ...
Posté par Guillaume Maillard (site web personnel) . Évalué à 10. Dernière modification le 02 septembre 2022 à 16:32.
Et bien, je t'invite à te renseigner sur le fonctionnement d'un serveur web, de la "mise en route" d'une connexion TLS.
La team "on est pas à 10Mo près et à 100ms près" me déprime.
(NDLR : mais bon, on est maintenant dans un monde de croyances assez folles, ou l'optimum c'est du node.js en docker. Et comme c'est à la mode, les biais cognitifs font que toutes réalités informatiques relatés par ceux qui connaissent l'assembleur, les vrais performances du matériel et les langages dits "bas niveau" par les ignares sont ignorées.)
[^] # Re: Si je puis me permettre ...
Posté par barmic 🦦 . Évalué à 1.
Dring<
Christophe B.<
Puis mon commentaire qui parle de la simplicité de HTTP et de l'overhead de TLS et TCP.
Avant de me balancer ta condescendance à la gueule, pourrais-tu lire ce à quoi tu répond ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Si je puis me permettre ...
Posté par Christophe B. (site web personnel) . Évalué à 3.
Je te prie d'accepter mes plus humbles excuses, la condescendance n'était pas voulue
Je voulais juste dire que l'échange de données peut être régler de manière plus simple que par des Web Services + oauth + …
tout dépend du contexte.
[^] # Re: Si je puis me permettre ...
Posté par barmic 🦦 . Évalué à 2.
C'est à Guillaume Maillard que je pensais.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Si je puis me permettre ...
Posté par Christophe B. (site web personnel) . Évalué à 2. Dernière modification le 05 septembre 2022 à 17:40.
OK Désolé :)
enfin plutôt ouf …
[^] # Re: Si je puis me permettre ...
Posté par barmic 🦦 . Évalué à 2.
La loi c'est toi ET L'ORDRE !
Je ne me permettais pas :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Si je puis me permettre ...
Posté par Christophe B. (site web personnel) . Évalué à 2.
Pour être honnête … c'est du bluff
mais bon avec un avatar bisounours tu perds pas mal en crédibilité :)
[^] # Re: Si je puis me permettre ...
Posté par PR . Évalué à 3.
Je travail moi aussi dans l’informatique bancaire, avec des techno. “très vieilles”.
Très régulièrement, je travaille sur des données qui passent par le mainframe ET des techno plus “modernes”.
Autant dire que j’ai pas mal d’occasions de constater les dégâts de la team. Moi je me marre dans mon coin. Il y a même pas deux semaines ils étaient en panique totale pour à peine 10k de données ; très innocent : « ah bon! ici c’est passé crème… »
Faut pas déprimer, sinon c’est un coup à se tirer une balle dans ce métier. Parce que dans mon cas ça a été du taf en plus pour leur connerie. Donc la prochaine fois que je vais traiter un volume inhabituel de données, je vais leur envoyer un petit mail bien mignon pour me foutre un peu de leur gueule… :-°
Mort aux cons !
[^] # Re: Si je puis me permettre ...
Posté par Christophe B. (site web personnel) . Évalué à 2.
On leur dira jamais assez … Fréquence et volume
Le ministère du numérique ne réponds toujours pas a ma proposition de faire tatouer sur les bras des devs ces 2 mots (même en petit) pour qu'il n'oublie pas
[^] # Re: Si je puis me permettre ...
Posté par steph1978 . Évalué à 3.
Je partage moyen car je ne vois pas en quoi un "format de serialisation"/"un protocole de transpor"e - bref du RPC - est réellement différent d'un autre. En tout cas ferait passer de "artillerie monstrueuse" à "un truc simple (?)".
Pour des utilisateurs humains, oui mais du coup on est plus vraiment sur du webservice mais plutôt de la webapp. En webservice, on va plutôt utiliser des API keys, des tokens.
Et du coup on met une API Gateway WAF. Vachement plus simple …
Alors oui mais ça c'est la sémantique REST qui est certes plus naturelle over HTTP mais qui aurait pu être mappée sur n'importe quel RPC.
Pas sûr que ce soit moins monstrueux du coup …
[^] # Re: Si je puis me permettre ...
Posté par Christophe B. (site web personnel) . Évalué à 6.
Pour résumer … en image :)
[^] # Re: Si je puis me permettre ...
Posté par Christophe B. (site web personnel) . Évalué à 6.
Et d'ailleurs toute la page vaut son pesant de cahuetes
12 Images pour comprendre
[^] # Re: Si je puis me permettre ...
Posté par steph1978 . Évalué à 2.
"inflate the baloon !"
[^] # Re: Si je puis me permettre ...
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4.
OAuth2 est une norme très générique et tu peux l'employer pour faire du webservice de backend à backend :)
La norme UMA 2.0 est justement prévue pour utiliser OAuth2 pour permettre à des tiers d'accéder aux données d'un utilisateur et tout ceci de manière asynchrone (le tiers peut demander l'accès et recevoir l'autorisation de l'utilisateur bien plus tard).
Malheureusement, la norme est assez complexe puis qu'elle définit beaucoup d'acteurs: un utilisateur avec son application, un service d'autorisation et un tiers avec une autre application.
En réalité, tous les acteurs ne sont pas nécessaires dans toutes les implémentations et donc des simplifications peuvent avoir lieu dans les interactions.
Je comprend bien que la norme doit pouvoir gérer les cas les plus complexes (comme l'accès aux dossiers médicaux par des médecins tiers), mais ça je pense que ça la dessert un peu, puisqu'elle est difficile à lire.
Ce que je trouve intéressant avec UMA 2.0 + OAuth 2.0, c'est que les backends sont enregistrés comme Client de OAuth2 (en tout cas avec l'implémentation de Keycloak). Du coup, si un des backends tiers n'est plus de confiance, tu peux juste le désactiver et il n'a plus accès à aucune donnée utilisateur de ton backend.
En plus, il y a un système de "Permission Ticket" qui détermine ce que tu as besoin comme droit pour faire ton action, qui vérifie si ta demande est conforme aux politiques de sécurités actuelles et qui te donne un token d'accès pour une durée limitée. Les politiques de sécurité sont configurables et protègent les ressources et/ou les "scopes".
Pour lier ton backend avec le serveur d'autorisation, il y a la norme UMAFedAuth qui permet de faire vérifier concrètement que les permissions ticket sont valides.
J'ai eu l'occasion de configurer un Keycloak avec tout ça. Grâce à UMA, j'ai évité de ré-inventer un système d'API token et j'ai eu pas mal d'avantages en plus:
[^] # Re: Si je puis me permettre ...
Posté par Ant . Évalué à 7.
C'était même le sujet d'un de mes projets de licence, en 1987 ! Implémenter un "chat live" à plusieurs participants, avec des fifos. Chaque utilisateur ouvrait 2 fifos sur un process hub central qui circularisait les messages entre les particpants.
J'ai réussi à le développer mais lors de la soutenance, bof : sur notre machine (une machine à processeur 68000 de 32 bits (!), avec 16 Mo de RAM, qui permettait pourtant à 10 utilisateurs sur terminal compatible vt100 de travailler), ça ramait affreusement. C'est là que j'ai découvert que les fifos, c'est lent, en tout cas sur nos machines de l'époque, car apparemment ça travaille vraiment sur disque. ça posait aussi des problèmes de sécurité : comment donner accès aux clients tout en protégeant le canal de comm et en empêchant aux autres utilisateurs de voir le contenu des messages ? (bon, il y avait des solutions)
J'ai découvert du coup que les files de message (msgget), un autre moyen de communication inter-process unix, ne posait pas ce problème de rapidité : l'échange est quasi immédiat.
Merci pour ce moment de nostalgie, je ne m'attendais pas à voir resurgir cette techno !
[^] # Re: Si je puis me permettre ...
Posté par Pierre Jarillon (site web personnel) . Évalué à 7.
Les messages, les sémaphores et la mémoire partagée, ce sont les IPC (Inter Process Communications) que j'ai beaucoup utilisé.
En 1992, j'avais installé Coherent, un Unix-like sur mon PC. Les IPC étaient émulés avec des fichiers et j'étais resté sur ma faim. En 1995, j'ai réussi à avoir un Linux : le bonheur !
C'était du vrai Unix, compatible avec le HP-UX que j'avais au boulot. Je travaillais en mode texte avec 4 écrans virtuels (Alt Ctrl Fn). Je pouvais créer, compiler et tester des petits utilitaires en C que je pouvais ensuite compiler sur HP-UX.
C'est alors, en 1995 que j'ai décidé de m'attacher à GNU/Linux.
En 2000, je n'avais plus de Windows à la maison et je ne l'utilisais quasiment plus au travail. Une sacrée page d'histoire
[^] # Re: Si je puis me permettre ...
Posté par lym . Évalué à 4.
Pour des besoins très très simples (notification d'évènements…) d'IPC, ne pas oublier les signaux utilisateur (SIGUSR1 et 2)!
Quand dans ma domotique j'ai voulu faire en sorte que le système d'alarme perso scripté dessus fasse sonner une liste de téléphones mobiles, ayant par ailleurs codé un service (en python) faisant du filtrage d'appel (recyclant un vieux modem 56k usb branché sur le RJ11 de la Livebox alors inutilisé, tous les téléphones utilisant sa base DECT intégrée), j'avais commencé à vouloir utiliser des tubes nommés et même codé un prototype en python.
Puis n'étant pas un programmeur système (mais plutôt très bas niveau en C/ASM) et n'ayant pas anticipé que ce serait un peu "too much", surtout que le côté alarme/domotique était scripté en Lua et la gestion du modem/filtre appel ou serait ajouté le côté liste de numéro à appeler en cas d'alarme était de son côté écrite en Python… En relisant ce dernier je passe sur l'accrochage d'un handler SIGINT tout ce qu'il y a de plus commun… et eurêka, j'ai alors repensé aux signaux utilisateur et tout est devenu bien plus simple!
Côté Lua, un os.execute de 'pkill -10 -f "python.*phoneFilter.py"&'
Côté service Python (nommé phoneFilter.py), juste accrocher le handler gérant la liste d'appels si alarme (sigusr1_handler) sur le SIGUSR1 (signal 10): signal.signal(signal.SIGUSR1, sigusr1_handler)
Et mon machin à filtrer les pubeux (d'un décroché/raccroché immédiat via le modem, sur blacklist de numéros individuels, préfixes d'allocation ARCEP, voir toute plage de numéros alloués à des opérateurs de VoIP s'étant révélés au fil des mois 100% chiants… et si pas en blacklist locale ni connu dans l'annuaire DECT de la Livebox, qui a alors le bon goût de remplir un nom dans le Caller ID, beautifulsoup interroge 2 services en ligne pour récupérer une classification… et l'ajouter a une blacklist locale pour le coup suivant) s'est vu ajouter simplement très simplement une fonctionnalité.
[^] # Re: Si je puis me permettre ...
Posté par Ant . Évalué à 1.
Effectivement, c'est élégant !
[^] # Re: Si je puis me permettre ...
Posté par Ant . Évalué à 1.
En 1995 j'avais un collègue avec autocollant "linux blabla" (je ne me souviens plus du contenu) sur son poste de travail, qui était une station de travail graphique Digital Equipement Corporation (une marque aujourd'hui disparue) sous un UNIX Digital, car nous travaillions à l'époque pour la finance et les applications étaient écrites en C et tournaient principalement sur l'Unix de DEC ou SunOS, les PC sous windows servant principalement à faire un peu de bureautique pour ceux qui ne voulaient pas investir sur un mac.
Je me souviens qu'à l'époque j'étais un peu intrigué et je me suis posé la question de l'utilité de linux, puisqu'il existait déjà de nombreuses variantes d'Unix dont le Xenix de MS et que selon moi le DOS et le windows de microsoft n'allaient pas s'imposer dans le milieu des serveurs ou des postes de travail exigeants, car bien inférieurs aux alternatives.
Je me suis bien trompé. Mais je ne suis venu à linux que bien plus tard, avec Mandrake 5 !
[^] # Re: Si je puis me permettre ...
Posté par lym . Évalué à 1.
Si IBM avait sélectionné les deux zozos proposant le pire OS (DOS: non multitâche/multi-utilisateur…) possible pour l'architecture ouverte de son PC originel en 1981, peut-être étais-ce aussi pour ne pas tuer trop vite leur (B de) business de stations Unix (traversé depuis l'origine, plus de 10 ans avant et une éternité pour l'informatique à l'époque, par la pile réseau) dès qu'Intel sortirait un processeur avec une MMU (ce qui est mieux pour le multitâche) et que qqun se dirait que les slots d'extension pourraient héberger une carte réseau!
Le premier windows avec support réseau (3.11 for workgroups) a sonné l'arrivée de la carte réseau accessible et les débuts de Linux. Le temps que cela prenne vraiment de l'envergure (au tournant de ce siècle), IBM avait gagné 20 ans et les zozos fournisseur du tas de merde étaient faits milliardaires!
[^] # Re: Si je puis me permettre ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
L'histoire est parfois juste malicieuse via de mauvais concours de circonstances. Je crois que le PC n'était pas pour faire survivre/pérenniser AIX (et leurs mainframes surtout) mais pour juste pour prendre un marché intéressant : le desktop qui commençait à se démocatriser et dont profiteront justement Commodore, Atari, Sinclair, etc. Pressés par le time to market (ce n'est pas une nouveauté), le grand bleu ne pouvait pas développer de système en interne à temps. La sélection des deux zozos s'est inscrit dans ce triste schéma où ces deux ont bénéficié de chance de cocus : c'est initialement Kendal, auteur de CP/M, qui avait été abordé mais la négociation a capoté pour des raisons bêtes et une personne bien placée (maman si j'ai bonne mémoire) a joué des coudes pour imposer les zozos. Que ce soit le pire OS n'est pas vraiment le fait de IBM mais de petit mou qui avait racheté QDOS un piratage inachevé de CPM et n'a jamais su le faire évoluer correctement (quand on compare à DR-DOS toujours sorti par Gary et ses équipes ensuite.) Si les gus de µ$ sont devenus milliardaires, c'est hélas parce-que les commerciaux de la grande firme n'ont pas eu les crocs et la foi dans le succès du PC, et ont donc consenti que les gus se fassent des royalties sur le pseudo-système qui sera vendu ensuite sur des clones…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Si je puis me permettre ...
Posté par Crao . Évalué à 3.
Pour avoir la véritable histoire de l'IBM PC, bien plus complexe et nuancée que ce qu'écrit Gil Cot, et sans ses remarques d'adolescent boutonneux, c'est ici :
https://arstechnica.com/gadgets/2017/06/ibm-pc-history-part-1/
https://arstechnica.com/gadgets/2017/07/ibm-pc-history-part-2/
[^] # Re: Si je puis me permettre ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Ah mais mon propos était justement que c'est nuancé et multifactoriel, contrairement au message initial qui laissait entendre un semblant de complot d'une grande boîte qui va exprès chercher un truc foireux pour préserver un autre business.
Le long article de Ars Technica représente à peine un chapitre de « Le hold-up planétaire : la face cachée de Microsoft » par Roberto Di Cosmo & Dominique Nora, ouvrage que je recommande chaudement.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Dans les avantages des webservices...
Posté par Dring . Évalué à 5.
…par rapport à un tube nommé, c'est aussi que ce n'est pas du point à point.
Quand on crée un webservice, il peut être utilisé…
- par l'interface utilisateur
- par des services extérieurs à l'entreprise
- par le petit process d'à côté
Et ça, c'est vachement pratique.
[^] # Re: Dans les avantages des webservices...
Posté par abriotde . Évalué à 3. Dernière modification le 02 septembre 2022 à 07:46.
C'est aussi son inconvénient. On ouvre à beaucoup un système qui n'a qu'un utilisateur au final et il faut restreindre à posteriori.
Parfois un accès sftp limité avec authentification que par clé parait plus pertinent.
[^] # Re: Dans les avantages des webservices...
Posté par Christophe B. (site web personnel) . Évalué à 4.
Tu as tout a fait raison, ce qui est dommage c'est que la plupart des informaticiens (je tapes large volontairement) n'ont plus le temps (ou le budget) de réfléchir et de choisir le bon outil pour le bon usage.
Quand tu as trouvé un bon marteau, tout tes problèmes ressemble a des clous
Et a force d'universaliser on se retrouve avec des couches et surcouches qui vont, comme les trous noirs, s'écrouler sous leur propre masse.
[^] # Re: Dans les avantages des webservices...
Posté par barmic 🦦 . Évalué à 3.
Pour contrebalancer un peu, si une application se met à interagir :
parce que chaque bout de l'appli a trouvé plus pertinent d'utiliser son truc qui fit parfaitement. Ce n'est pas une solution.
Et le curseur d'où est-ce qu'on rationalise par rapport à faire le choix spécifique dépend des équipes. Une petite équipe et/ou moins technique rationalisera probablement plus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Dans les avantages des webservices...
Posté par Christophe B. (site web personnel) . Évalué à 7.
Oui cela dépend de l'échelle du projet
Mais quand je vois des préconisations ou des installations avec du SSL de partout, alors que les composants sont sur une seule machine.
cela me fait penser au type qui pose des digicodes sur toutes les portes de sa maison (y compris les toilettes) avec rotation à la semaine des codes :)
Il serait pas plus simple de sécuriser les accès extérieurs et de laisser l'intérieur tranquille non ?
[^] # Re: Dans les avantages des webservices...
Posté par barmic 🦦 . Évalué à 2.
Ça dépend. Est-ce que ce sont 2 choses qui sont effectivement toujours sur la même machine ? Est-ce que ça le sera toujours ? Ça dépend du ou des security threats qui te concernent.
C'est toujours plus simple de ne pas faire de sécurité, mais la difficulté n'est pas forcément une métrique très pertinente pour savoir si ça vaut le coût ou non. Particulièrement en matière de sécurité qui peut vite s'avérer rébarbatif sans apporter de fonctionnalité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Dans les avantages des webservices...
Posté par abriotde . Évalué à 1.
Je pense que si c'est sur une même machine il y a plus simple. Et si dans 5-10 ans c'est explosé sur plusieurs, il y aura un dev dédié, s'il n'y a pas une refonte d'ici là.
[^] # Re: Dans les avantages des webservices...
Posté par barmic 🦦 . Évalué à 1.
Des fois c'est 2 ou 3 semaines ou simplement dépendant de comment tu fais ton déploiement, de la charge ou de la résilience souhaitée.
On sait en plus maintenant faire du TLS configuré semi automatiquement assez transparent.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Dans les avantages des webservices...
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 02 septembre 2022 à 21:11.
Ah évidemment comparaison n'est pas raison
C'est comme si l'on appliquait le code de la route qu'hors des villes.
Lien avec les motards un vendredi. C'est un conte kem's ! :p
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Dans les avantages des webservices...
Posté par Christophe B. (site web personnel) . Évalué à 4.
Le code de la route est utile à l'extérieur pour rouler avec les autres
Quand je roule dans ma propriété je n'ai pas besoin du code de la route
Ma vision de la sécurité est la suivante :
Bâtir un château fort avec pont levis, parapet tour de garde etc …
mais dans le château fort pas besoin de serrure, ou alors sauf pour des données très sensibles comme les paies
Alors c'est vrai les failles il y en a : les postes utilisateurs qui vont chez les clients et/ou voyagent (wifi public etc … ) par exemple
Pendant longtemps je ne voulais même pas de wifi, tant que je n'avais pas trouvé un parefeu capable de gérer correctement Wifi interne et "Invité"
Mais bon quand tes collègues font n'importe quoi et donne les codes wifi internes aux clients … comment veux tu gérer correctement de la sécurité
La sécurité c'est d'abord du bon sens puis de la formation
[^] # Re: Dans les avantages des webservices...
Posté par barmic 🦦 . Évalué à 4.
Donc les droits unix tu pense que c'est de trop par exemple ? Les LSM, la gestion d'utilisateurs, etc pareil ? La distinction kernelland/userland ? Les switch de context que ça implique nuisent aux performances et ça demande beaucoup de configuration bien complexe. Perso je joue avec TLS tranquillement et je comprends rien à SELinux.
Ta métaphore fais écho à cet article : The End of the Fortress Metaphor [EN].
La sécurité c'est avant tout une science donc non pas du "bon sens" (et globalement à chaque fois qu'on se dit que quelque chose est de l'ordre du bon sens faut faire gaffe). Au niveau le plus bas, tu applique des principes (mots de passe utilisateurs enregistrés salés et hashés par exemple) et quand tu monte tu va jusqu'à définir tes menaces de sécurité (security threat pour les recherches sur internet) et ainsi faire tes propres choix.
Je ne dis pas qu'il faut mettre du TLS partout, mais que l'argument du bon sens et de trouver ça complexe ne sont pas de bon conseillers.
Pour rappel la RGPD crée un délit de manque de sécurité. Il faut sérieusement que la sécurité ne soit plus une variable d'ajustement traitée au bon sens quand ça nous embête pas trop.
Les security threats c'est ce que la CNIL recommande avec l'"approche par les risques". Ici il est question de savoir si un attaquant peut ou pas exécuter du code arbitraire sur la machine si tu ne considère pas que c'est possible alors non seulement le chiffrement offert par TLS est inutile, mais je ne vois pas en quoi gérer des droits sur la machine est utile.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Dans les avantages des webservices...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Bah ça distingue l'extérieur et l'intérieur (ou plutôt l'individu et le groupe proprio du reste du monde) là où d'autres multiplient inutilement. Ça distingue grossomodo trois niveaux d'accès (consultation, modification, totale) là où d'autres ont une granulation plus compliquée. Après c'est sûr que si tu viens de DOS c'est beaucoup plus qu'on en gère mais il ne faut pas oublier que c'est en vase mono-user full-access mono-task.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Intéressant mais...
Posté par Marcel4567 . Évalué à 5.
Intéressant rappel d’une vielle technologie UNIX oubliée.
Ceci dit, deux points :
La grande majorité des communications entre "process" se fait vers des machines différentes (voire datacenter différents) sur des réseaux non sécurisés. C’est fout de voir la quantité de truc qui passe sur internet de nos jour, de la station météo au distributeur de croquettes.…
Pour les utilisations en localhost, les tubes nommés sont bloquant d’une façon assez pernicieuse et au final plutôt difficile a utiliser d’une façon fiable. Et ne gère la communication qu’entre 2 process. L’utilisation de socket UNIX à la place est à mon avis plus simple et plus efficace, et permettent de gérer plusieurs client multiplexés. Le code est aussi très similaire a un socket INET traditionnel, ce qui fait le passage de l’un à l’autre très facile.
# C'est intéressant mais
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 2.
dans les grosses boites, on a pas le choix, on doit s'adresser au "service qui va bien" et c'est eux qui vont gérer. Ce qui est pénible dans ce cas là, c'est de spécifier son besoin.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.