Discussion :

[Grogro]

Mais je comprend bien que si les performances ne sont pas un problème, ou si on est pas maitre de l'interface et que de l'autre coté du tuyau il y a des changements fréquents non documentés, un format autoporteur est nécessaire. Je pense juste que c'est crado ^^

Oui mais voilà, la vraie vie c'est souvent crado et on a pas toujours la totale maitrise de toutes les couches du SI. Et plus on creuse le merdier, plus on se rend compte à quel point c'est sale. Mais ça fonctionne (la plupart du temps). ^^

Merci pour tes précisions techniques en tout cas. Tel que tu le décris, Protocol Buffers n'a pas l'air plus lourd à déployer que du SOAP.

[AoCannaille]

Oui mais voilà, la vraie vie c'est souvent crado et on a pas toujours la totale maitrise de toutes les couches du SI. Et plus on creuse le merdier, plus on se rend compte à quel point c'est sale. Mais ça fonctionne (la plupart du temps). ^^

C'est peut être l'avantage de taffer dans le militaire

Merci pour tes précisions techniques en tout cas. Tel que tu le décris, Protocol Buffers n'a pas l'air plus lourd à déployer que du SOAP.

De rien :-)
Les seules conditions dans lesquelles j'ai utilisé du SOAP et du REST était pour des web services sous JBOSS (j'ai l'impression que c'était il y a une éternité). Effectivement, Eclipse bien configuré (ce qui n'était pas donné non plus), facilitait pas mal le boulot. Avec protobuf, le seul truc "fastidieux", c'est le méga switch case à l'entrée et a la sortie du tuyaux... rien d'insurmontable non plus.

[professeur shadoko]

je suis assez surpris:
1) ah bon il y a des applications qui font de la Serialization sur du réseau non-local/privé?
2) quand bien même, si on a peur d'intrusions, qu'est ce qui empêche d'authentifier des MarshalledObjects (ou de passer par un canal authentifié)?
En partant à la retraite j'ai quitté un projet java (gros matériel scientifique) qui doit être opérationnel en 2020 sur une durée de 20 ans .(avec une multitude d'ordis qui s'échangent en local, et à toute vitesse, des tonnes d'objets).. tout à coup j'ai des sueurs froides ....

[thelvin]

1) ah bon il y a des applications qui font de la Serialization sur du réseau non-local/privé?

Ben oui... Pour une appli web, supposons que tu aies besoin de conserver une donnée avec une certaine permanence côté client. Ben tu la sérialises dans un cookie, problème réglé. Qu'est-ce qui pousserait à penser à faire autrement ?

2) quand bien même, si on a peur d'intrusions, qu'est ce qui empêche d'authentifier des MarshalledObjects (ou de passer par un canal authentifié)?

Ben rien ne t'empêche de le faire, d'ailleurs je dirais que c'est indispensable si tu décides d'avoir un mécanisme de ce genre (je vois pas, par contre, ce que ça peut changer si c'est un canal authentifié. Tu penses qu'un pirate ne songeras pas à prendre un compte client chez toi pour te pirater ?)

Le problème c'est que les objets marshallés, c'est pas toi qui t'en occupes, c'est les bibliothèques dont tu te sers. Et elles étaient à des kilomètres de s'imaginer qu'on pourrait s'en servir dans un contexte où il faudrait vérifier qui demander à désérialiser quoi. Du coup, ben, elles ne le font pas.

Les failles de ce genre que l'on connaît, ont bien entendu été corrigées dans des versions plus récentes maintenant que rétrospectivement ça a l'air évident pour tout le monde une fois qu'on le sait. Mais, quid de ceux qui ne mettent pas à jour, et surtout, ça montre que les failles de ce genre peuvent arriver comme un rien. Il y a aussi toutes celles qu'on ne connaît pas.

En partant à la retraite j'ai quitté un projet java (gros matériel scientifique) qui doit être opérationnel en 2020 sur une durée de 20 ans .(avec une multitude d'ordis qui s'échangent en local, et à toute vitesse, des tonnes d'objets).. tout à coup j'ai des sueurs froides ....

Sans maintenance, en Java ou ailleurs, ce genre de choses n'existent plus... Pour les applications non connectées, on avait pas à s'inquiéter de faille de sécurité, et le matériel très robuste et durable faisait qu'on n'était pas tenu de mettre régulièrement à jour. C'est fini tout ça. À la rigueur, la partie durable peut toujours se réinventer... Mais l'aspect faille de sécurité potentielle, non. Pas à un époque où on sait trouver des failles comme Spectre ou Meltdown.

[Badshade23]

Bonjour tout le monde,
J'ai lu tous vos différents posts avec beaucoup d’intérêt.
Tout d'abord, je suis novice dans le domaine de la sérialisation. Je travaille actuellement sur un projet en swing et nous sérialisions au début les objets via JAXB pour les avoir en XML. Le problème était que certains utilisateurs s’amusaient à changer les données stockées en XML car totalement lisibles via un logiciel tel que notepad++. Puis ils nous appelaient pour se plaindre que le fichier n'était plus accepté par l'application (rien d’anormal surtout s'ils suppriment une partie d'une balise...). Nous avons réfléchi à plusieurs solutions et au lieu de chiffrer les objets sérialisés en XML, nous avons choisi de les sérialiser en octet.
Sachant que pour désérialiser les objets nous avons besoin de la classe de celui-ci, je ne vois pas comment il pourrait y avoir un danger ?
Après mon cas est différent mon projet n'est pas ouvert à internet donc les risques de piratage sont plus que minimes.
Je ne vois pas en quoi cette pratique est néfaste surtout que niveau lourdeur du code il n'y a pas photo ça reste extrêmement simple par rapport à l'XML ou JSON ou autres (à mon avis). À part pour le débogage, je ne vois pas vraiment de côté négatif (dans mon cas en tout cas).
Après je n'ai pas le recul de la plupart d'entre vous. Je suis donc preneur de tout conseil ou remarque^^....

[AoCannaille]

Bonjour Badshade23,

Si ta sérialisation n'est utilise que pour la persistance, le XML était effectivement une solution viable, son seul problème étant que ce n'est pas idiot-proof
Tu peux bricoler ton fichier pour limiter la part d'idiot, le nommer *.data par exemple, ou *.<nom de ton logiciel>, tu auras déjà 80% des idiots qui, s'il ne suffit pas de double cliquer, n'y toucheront plus. Peut-être également le rendre fichier caché.

Tu peux sinon effectivement sérialiser en binaire. Avec google protocol buffer, au lieux d'envoyer les octets dans une socket, tu le fait dans un fichier et le tour est joué.

Tu peux aussi te renseigner sur sqlite. C'est une base de donnée relationnelle sous forme de fichier (donc contenu binaire) et qui avec les outils adapté est "débogable". Le commun des mortel ne pouvant pas y toucher. C'est utilisé par exemple par firefox pour enregistrer préférences et personnalisations.

Par contre, en fonction de ton architecture actuelle, ça demandera sans doute plus d'effort que la sérialisation binaire.

[Badshade23]

C'est sur pour "l'idiot-proof" .
J'ai déjà changé l'extension mais bon ça ne change malheureusement rien .
Je connaissais pas google protocol buffer j'ai vu qu'il était mentionné dans les commentaires précédents.
Quant à SqlLite j'en ai déjà entendu parler mais plus pour Android.
Mais sa ne change pas le fait que je ne comprends pas où serait la faille de sécurité sachant que pour désérialiser les objets nous avons besoin de la classe de celui-ci?