Discussion :

[goldbergg]

Merci pour ce petit moment de gourmandise, j'étais sûr que tu allais me sortir un truc du genre "olol il é tro bet on peu utilisé lé objé kom tablo assosiatif !"

Ben oui, je suis au courant, c'est pour ça que j'ai dit pas de véritables tableaux associatifs !

De un c'est dégueulasse comme manière de bosser, c'est du pur bricolage. Un tableau est un tableau, un objet est un objet. Accéder à un objet comme un tableau avec un instruction du genre "objectName['keyName'] n'a aucun sens et rend le code illisible.
De deux, les objets ne fournissent pas les mêmes possibilités que les tableaux. Le premier exemple qui me vient à l'esprit est que l'on ne peut pas exécuter un pop sur un objet, mais j'ai déjà eu des dizaines de cas où ces limitations m'ont fait perdre un temps fou.

Comme dit dans mon précédent post, il existe les Map en JS qui sont de vrais dictionnaire avec une api complète :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Map.prototype.clear()
Map.prototype.delete()
Map.prototype.entries()
Map.prototype.forEach()
Map.prototype.get()
Map.prototype.has()
Map.prototype.keys()
Map.prototype.set()
Map.prototype.values()
Map.prototype[@@iterator]()

Donc oui il y a de vrais tableau associatif natif en JS.
N'importe qui ayant lue un minimum la doc est au courant que ça existe.

Aussi, si une fonctionnalité manque en JS, rien n'empêche de la créer soit même:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Object.prototype.pop = function()
{
    var ks = Object.keys(this);
    var last = ks[ks.length -1];
    if(last  == null) return null;
    var val = this[last];
    delete this[last];
    return val;
};
var obj = 
{
    "key_a" : "val_a",
    "key_b" : "val_b",
    "key_c" : "val_c",
};
console.log(obj.pop(), obj); //val_c,  {key_a: "val_a", key_b: "val_b"}

Sa fait partie des forces du langage, via les prototype on peux étendre un peux prés tout et n'importe quoi (mais bon, je présume que tu vas me dire que c'est dégueulasse et que c'est juste du bricolage de faire ce genre de chose).

Et sinon je vois pas en quoi le faite que les object en JS ne soit en faite que des dico soit dégueulasse, pour la énième fois JS c'est pas du C++ (ou tout autre langage POO par Class)... Il serait temps d'accepter que le JS est son propre mode de fonctionnement.

[ijk-ref]

(…) par quel langage tu souhaiterais remplacer Javascript

WebAssembly comme ça tout le monde pourra utiliser le langage qu'il souhaite

[ddoumeche]

Amusant cette manie de vouloir refaire les IHM en language de script, que ce soit en Javascript ou autre.

Cela facilite grandement le hacking puisqu'une fois que l'on peut injecter du code dans le thread principal (ce qui est assez simple aujourd'hui), il n'y a plus de cloisonnement des processus et on pourra donc piloter tout Office via Javascript.

[SpaceFrog]

Déja que le fichiers offices sont des zip et que les mot de passe y sont en clair ^^

[Marco46]

Cela facilite grandement le hacking puisqu'une fois que l'on peut injecter du code dans le thread principal (ce qui est assez simple aujourd'hui),

Tu m'étonnes, il suffit d'appuyer sur la touche F12 et de cliquer sur l'onglet "console", un vrai scandale !

Cela facilite grandement le hacking [...] il n'y a plus de cloisonnement des processus et on pourra donc piloter tout Office via Javascript.

C'est qui "on" ? Qui est l'attaquant et qui est la victime dans ton scénario ?

Autre question qu'est-ce que tu appelles le cloisonnement des processus et en quoi 2 processus Node seraient plus ou moins cloisonnés que des binaires .NET ou des jar exécutés sur la JVM ?

[Bono_BX]

Autre question qu'est-ce que tu appelles le cloisonnement des processus et en quoi 2 processus Node seraient plus ou moins cloisonnés que des binaires .NET ou des jar exécutés sur la JVM ?

Pour la JVM, je ne connais pas les détails de la gestion mémoire. En .Net, en effet, chaque process a un pool de ressource dédié et cloisonné, non accessible par d'autres process (je simplifie, mais l'idée est là).
Je suppose que ddoumeche veut dire qu'en JS, la gestion de la mémoire et des process sera gérée par le navigateur / l'interpréteur JS, donc ce cloisonnement ne dépendra plus de la plateforme du langage (JVM, CLR, etc.), mais d'un acteur tiers qui sera potentiellement non sécurisé.

[loulnux]

Pourquoi Microsoft
- Fait les doux yeux à Linux?
- Fait les doux yeux au "Libre"?
- Aurait peut-être tendance à virer Java?

Et pourquoi Microsoft peine à percer sur le monde ARM?

Parce que un jour Microsoft a décidé d'abandonner l'entretient de l'HAL des processeurs RISC au profit du .NET Framwork qui a eu l'avantage de faire cohabiter 32/64 par la suite en toute transparence sans pousser les mainteneurs à adapter leur code.

Or ces dernières années Microsoft a tenté d'investir le monde du mobile (principalement ARM) sans remettre en question l'utilisation de cette verrue antinomique avec le mobile : ce qui est déjà très gênant sur un desktop/laptop "n'éteignez pas votre ordinateur, veuillez patienter"... et la même chose au re-démarrage, n'est de toute évidence pas envisageable sur un téléphone et ce phénomène est principalement du au .Net.

Personnellement j'ai tout comme l'impression que Microsoft est entrain de constater que :
- Le mobile est gentiment entrain de bouffer les parts de marché du pré carré du fixe.
- Les applications SaaS sont en général servies par des serveurs LAMP.
- Il est de plus en plus difficile de maintenir un système de terminal entrain de devenir totalement exotique et payant (Win10 plus de 2 ans d'existence et encore instable).
- Ses revenus ne dépendent plus de la vente de ses systèmes et logiciels "traditionnels" mais de ses services Cloud et connexes.

Alors il serait tellement plus pratique "d'offrir" une simple interface (coquille) signée Microsoft avec un store rempli des mêmes offres que les concurrents?
Qu'importe le flacon... pourvu qu'on ait les soussous dans la popoche?

[ddoumeche]

Tu m'étonnes, il suffit d'appuyer sur la touche F12 et de cliquer sur l'onglet "console", un vrai scandale !

Avec un navigateur oui, mais c'est aussi faisable pour un exécutable lambda : une l'injection de DLL (ce qui n'est en réalité guère compliqué) permet d'obtenir une référence vers la librairie de l'interpréteur javaScript de l'exécutable cible : cette dll va alors pouvoir utiliser l'API pour injecter du code sous forme de chaîne de caractère via un executeScript(), avec des callback divers, ou redéfinir du code vu que tout est dynamique.

Ce qui n'est pas fondamentalement différent des virus de mail en Visual Basic que l'on a pu connaitre il y a fort longtemps. J'ai récemment vu le cas d'un malware utilisant LUA pour infecter un jeu en ligne, pourtant protégé. Sidérant.

C'est qui "on" ? Qui est l'attaquant et qui est la victime dans ton scénario ?

Autre question qu'est-ce que tu appelles le cloisonnement des processus et en quoi 2 processus Node seraient plus ou moins cloisonnés que des binaires .NET ou des jar exécutés sur la JVM ?

"On" étant le hacker.
Je voulais dire que le cloisonnement entre modules, API et code ne devait pas exister en Javascript voir dans les langages de script en général.

Java et .Net (de mémoire) ont un Security Manager limitant entre autre l'accès au système de fichier.
De plus sur un serveur web (Tomcat par exemple), tu ne peux pas accéder au code et aux ressources d'autres applications, sauf éventuellement en passant par l'instrumentation (JMX) qui doit avoir été explicitement autorisée par l'administrateur système.
Et Java a implémenté les modules en version 9 pour remettre un peu d'ordre, sachant qu'auparavant tu pouvais (et tu peux encore) appeler du code non public des librairies standard.

J'imagine que .Net utilise des mécanismes de sécurisation similaires. Et il y a eu énormément de mise à jour de sécurité sur ces deux plateformes depuis quelques années.

Mais dans Nodejs, il y a beaucoup de failles et il n'y a aucune sécurité, car le security manager de V8 est désactivé. Certes la majorité de ces failles est inexploitable ... pour l'instant et tant que personne n'a trouvé moyen de les exploiter.
Et comme dit plus haut, on peut redéfinir les fonctions des modules voir les fonctions natives via un simple eval() (imaginez qu'un assaillant redéfinisse mysql.connect). Imaginez les dégats que risquent de faire un vers

Donc pour l'instant, il vaut mieux le savoir et faire tourner son Node.js dans un espace cloisonné comme un container, en le gardant à l’œil et sans lui donner trop de responsabilités.

Je suis un peu plus circonspect sur ces applications embarquant des moteurs de javascript de partout.