Mais ? Le développement front-end est un bordel sans nom ?! - Page 5

(en plus c'est pas très gentil )

Zerosquare (./120) :

Brunni (./118) :
j'ai reconnu le commentaire de squalyl juste apres, typique des gens non comprehensifs qui ont ont fait partie ma propre vie et qui n'ont jamais vraiment eu de questions à se poser sans pour autant réaliser leur chance -- que rétrospectivement j'aurais envie d'égorger

(n'égorge pas Squalyl STP, il peut nous être utile )

Nan mais je rétrospecte pas là ça va

Tant mieux ^^

http://status.npmjs.org/incidents/dw8cr1lwxkcr
...

A propos de node:

http://stackoverflow.com/questions/4482686/check-synchronously-if-file-directory-exists-in-node-js

fs.exists() is an anachronism and exists only for historical reasons. There should almost never be a reason to use it in your own code.
In particular, checking if a file exists before opening it is an anti-pattern that leaves you vulnerable to race conditions: another process may remove the file between the calls to fs.exists() and fs.open(). Just open the file and handle the error when it's not there.

Il est bien sur inutile de vouloir verifier si un fichier existe hein, histoire de ne pas l'écraser par exemple

et bien sur

Side note: You've expressly asked how to check synchronously, so I've used the xyzSync versions of the functions above. But wherever possible, with I/O, it really is best to avoid synchronous calls. Calls into the I/O subsystem take significant time from a CPU's point of view.

Bien sur on fait toujours des choses completement asynchrone, comme par exemple determiner le premier nom de fichier non utilisé en ajoutant par exemple un "-X" ou X est un nombre dans le nom de fichier pour eviter les clashs (et si un des fichier disparait OSEF, ce qu'on veux c'est NE PAS ECRASER un fichier existant, en plus ce edge case est particulierement peu courant et depends completement du projet. Supprimer une fonction pour une telle raison est juste stupide, comme le dit qq'un sur le SO, il y a des utilisation plus que legitime de savoir si un fichier existe et se sans chercher a l'ouvrir absolument, parceque la raison n°1 c'est qu'on s'en fout du fichier en lui meme et de ce qu'il contient)

0^2 & Godzil >

(Godzil > sans compter qu'on peut partir du principe que certains fichiers appartiennent au programme, et que s'ils sont modifiés par un autre process c'est tant pis pour l'utilisateur)

Oui, en l'occurence je suis tombé sur ce probleme en corrigeant un truc qui fait du téléchargement en masse, mais ne vérifie pas qu'un fichier existe avant de telecharger..

Godzil (./125) :
Il est bien sur inutile de vouloir verifier si un fichier existe hein, histoire de ne pas l'écraser par exemple

Je ne suis pas vraiment d'accord. Tester l'existence d'un fichier avant de l'ouvrir est effectivement une race condition, et il y a justement un mode d'ouverture qui n'écrase pas le fichier s'il existe déjà pour gérer le cas que tu cites (mais je ne sais pas si node.js le supporte).

Godzil (./125) :
Bien sur on fait toujours des choses completement asynchrone, comme par exemple determiner le premier nom de fichier non utilisé en ajoutant par exemple un "-X" ou X est un nombre dans le nom de fichier pour eviter les clashs (et si un des fichier disparait OSEF, ce qu'on veux c'est NE PAS ECRASER un fichier existant

Justement, avec la race condition, tu risques d'écraser un fichier existant (si celui-ci est créé entre le moment où tu vérifies l'existence et le moment où tu le crées toi-même). Alors bien sûr, il y a des cas où une telle protection est superflue parce qu'on sait que ça ne se produira pas, mais conceptuellement ça reste une mauvaise pratique.
Pour les fonctions asynchrones, ça ne me paraît pas abusif de les recommander, il y a trop de gens qui écrivent du code synchrone qui bouffe du CPU et de la batterie.
Après, je suis d'accord qu'aller jusqu'à supprimer les "anciennes" fonctions est abusif.

La race condition n'existe que dans sun environement non controlé, en l'occurence l'environment l'est et personne d'autre que le programme en question ne touche/créé/supprime les fichiers dans les dossiers en question.

Et non les seuls cas, dans ce cas, ou les fichiers peuvent disparaitres/aparaitres sont des manipulation de l'utilisateurs, mais il faut etre un peu con pour le faire dans ce cas la.

En l'occurence bis, le besoin de tester la est a cause d'un bug du coté de ce qui est a télécharger (et on a aucun controle la dessus) ou certains infos sont foireuses, ce qui fait que recuperer ces infos mene a remplacer un fichier existant. C'est long et compliqué a expliquer, mais le seul moyen de faire que les choses marchent correctement sans risque d'écrasement est de pouvoir vérifier l'existence d'un fichier dans mon cas précis. Et les fonction ouvrir ne sont d'aucune utilité la.

http://stackoverflow.com/questions/230062/whats-the-best-way-to-check-if-a-file-exists-in-c-cross-platform ?

en es5 ça donnerais un truc du style, en utilisant asyncvar async = require('async'), fs = require('fs'), n = 0, path = './toto'; async.forever(function(next){ fs.stat(n ? path+n : path,function(err,stat){ if( !err && stat.isFile() ){ n++; next() } else next(true); }); },function(err){ console.log( n ); });
et avec des promises qq chose du genre :var path = './toto', fs = require('fs'); function isFile(f){ return new Promise(function(resolve){ fs.stat(f,function(err,stat){ resolve( !err && stat.isFile() ); }); }); } function check(done,n=0){ isFile(n ? path+n : path).then(function(exist){ if(exist) return check(done,n+1); done(n); }); } check(console.log);
> Bien sur on fait toujours des choses completement asynchrone
c'est le principe à la seconde ou tu as des io ou équivalent.

> si un des fichier disparait OSEFvar now = new Date().getTime(), dir = './db/dump/' + req.params.db, file = dir + '/dump.'+now+'.sql.gz' ; ?

Ton dernier exemple a seulement moins de chances de foirer, mais il n'est toujours pas 100% sûr.

ces vraiment atroce ces syntaxtes...

ainsi que l'argument "oui mais synchrone c'est long", on fait pas

NON NON NON, on fait pas AVEC NODE, c'est node qui a introduit ce genre de code, c'est pas général !

squalyl (./132) :
ces vraiment atroce ces syntaxtes...

Oui :/

ainsi que l'argument "oui mais synchrone c'est long", on fait pasNON NON NON, on fait pas AVEC NODE, c'est node qui a introduit ce genre de code, c'est pas général !

^9000

https://snyk.io/vuln/npm:secure-compare:20151024
Bon, c'est plus possible là : c'est une blague

Un double facepalm n'est meme pas suffisant o_o

TORGNOLES

Bah dans un code comme ça comment tu veux ne pas t'y perdre ?
https://github.com/Snyk/vulndb/blob/snapshots/master/patches/npm/secure-compare/20151024/secure-compare_20151024_0_0_b768f45003dad04743c91747e35df1b0a4c4c897.patch

Même sans cet énorme bug, le principe-même de ce machin est stupide. On ne peut rien garantir vis-à-vis des side-channel attacks à un niveau d'abstraction aussi élevé, parce qu'on ne sait absolument pas comment le code sera interprété/optimisé/compilé (et comment ça évoluera dans le futur quand les plateformes évolueront) : même si le code est "parfait", ça ne garantit rien sur le comportement réel du système concret. En bref c'est de la poudre aux yeux.

Uh?
Utiliser le xor pour verifier que c'est identique ???

sans parler de la creation du depot github qui est vraiment savoureux!
https://github.com/vdemedes/secure-compare/commits/master

Ils ont réussi à faire 17 releases pour cette comparaison

Lit bien l'origine du depot (fork from) et l'historique sur githib c'est pire que ca

Zero: Oui absolument, mais ca permet de dire au chef "j'ai mis des comparaisons sécurisées"

Godzil: Oh y'a pas que xor
bool flag = true;
for(i=0;i<len;i)) flag &= (a[i] == b[i]);
return flag;

ca permet de faire des versions parano anti injection de faute:

bool flag = true;
for(i=0;i<len;i)) { flag &= (a[i] == b[i]); flag &= !(a[i] ^ b[i]);}
return flag;

c'est aussi en temps constant ^^

Sur un language basé sur une VM non predictible, je suis pas sur que ca soit du temps constant mais bon

Wow et trois versions majeures pour un bout de code qui n'a visiblement même pas été testé une seule fois, pas même à la main. Mais la faute revient aux projets qui utilisent cette lib s'il y en a, après tout chacun a le droit de diffuser son code aussi pourri soit-il.

Le problème, c'est surtout que ce truc s'appelle "secure", mais est source probable de nombreux trous de sécurité (sans compter les autres bogues que la comparaison foireuse produit).

Laissez-moi deviner, c'est évidemment lié statiquement, donc tous les sites qui ne seront pas reconstruits avec la nouvelle version l'auront violemment dans l'os ? Ca vaudrait le coup de créer un script d'exploit rien que pour ça, tiens, heureusement pour eux que je ne sais pas faire

La notion de "lié statiquement" est un peu différente en JS, les utilisateurs de cette bibliothèque pourraient fusionner son code à l'intérieur de leurs scripts (plus ou moins équivalent à une compilation statique) ou bien laisser le script à côté sur leur serveur et y faire référence (équivalent à une DLL). Mais dans les deux cas le correctif ne sera pas disponible pour eux tant qu'ils n'auront pas mis à jour puis re-déployé leur site.

La seule solution qui leur aurait permis d'être immédiatement à jour est de référencer le script directement sur le serveur d'origine (par exemple GitHub), c'est à dire le hotlinker. Mais déjà ça n'est pas toujours autorisé (ça risque de faire beaucoup de requêtes sur ce serveur), et ensuite c'est aussi un problème de sécurité puisque tu exécutes un script "étranger" sur ton site.

En termes de compilation ça serait équivalent à télécharger une DLL sur un serveur distant lors de l'exécution d'un programme, puis la charger dynamiquement et l'exécuter (d'ailleurs c'est un peu ce qu'il se passe avec les protections de certains jeux vidéo maintenant)

un troll quoi

Putain mais comment tu peux avoir envie de manger ça #berk#



(c'est une question rhétorique, un Amercain baverait là devant. J'ai jamais pu comprendre.)