Brouiller du code JavaScript

Version imprimable

28/06/2007, 01h45
Hibou57

Brouiller du code JavaScript

Bijour, bijour,

Est-ce qu'ils existent des solutions pour brouiller du code JavaScript ? Je pense à ça dans une optique de protection du code (qui n'empêcherait malheureusement pas la copie cependant).

EDIT 29 juin 2007
Edit du 29 supprimé (correction)
EDIT 30 juin 2007
Voici finalement une bonne solution :
Dojo shrinksafe
(voir le post n°20 pour les détails)
Il en existe peut-être d'autres, et si vous en connaissez, n'hésitez pas à les indiquer dans ce fil. Mais avant de les annoncer, prennez soin de les vérifier en tenant compte des critères de fiabilité indiqués dans le post n°20.
28/06/2007, 02h22
laurent_m

Humm techniquement, ça demeure possible mais je ne sais pas s'il y a des solutions toutes faites.

Que veux tu faires précisément ? Obfuscation de code ?
Ton code js est-il directement dans la page ou dans un fichier ?
Avec quelle technologie utilises-tu JS? PHP?

Dépendant de tes réponses on verra ce qu'il est possible de faire :)

@+
28/06/2007, 02h57
Hibou57

Déjà une réponse si vite :D

Oui, c'est apparement le terme, je me suis renseigné : obfusquer, c'est apprement comment ça qu'on dit.

Pour répondre à tes demandes d'informations :
Ce n'est pas pour du PHP, mais seulement du JavaScript, et le JavaScript sera dans des fichiers externes (je suis partisans de la séparation du document et du comportement)

J'ai voulu essayer la version trial de JavaScript Obfuscator (valable 30 jours apparement)... mais ça ne marche pas : le renomage ne semble pas fonctionner, et il n'arrive même pas à retirer les commentaires, alors que j'ai pourtant bien coché l'option. (je me demande comment ils peuvent vendre ça... heureusement que ce n'était que du trial... et puis même 30€, c'est de toute façon trop chèr pour moi)

J'en ai vu un en ligne sur un site, mais qui ne fonctionne pas non plus.

Ca doit bien exister pourtant, puisque Google le fait avec les codes associés à AdSense...
28/06/2007, 03h02
laurent_m

Je regarde ça au courant de la semaine et je te reviens là-dessus :P
28/06/2007, 09h18
SpaceFrog

Je ne vois pas trop l'intérêt de masquer du code javascript ...
Aucune opération nécessitant un minimum de sécurité ne devrait être faite en javascript ... Le seul moyen est de passe en langage serveur ...

Il existe des tonnes de freeware pour chiffrer du code javascript...
http://www.google.fr/search?hl=fr&cl...eeware&spell=1

Pour moi ça ne reste que du gadget très peu efficace
29/06/2007, 01h17
Hibou57

Citation:

Envoyé par SpaceFrog

Je ne vois pas trop l'intérêt de masquer du code javascript ...
Aucune opération nécessitant un minimum de sécurité ne devrait être faite en javascript ... Le seul moyen est de passe en langage serveur ...

Mais je ne peux quand même pas faire une requête serveur à chaque commande de l'interface. Cette application ne s'y prétera pas, car pour des raisons de fluidité évidente, une trés grande partie sera en JavaScript, et seule certaines opérations « de finalisation » passeront par une application sur le serveur. Il y aurait de toute façon beaucoup trop de données à transmetttre à chaque requête (si tu pensais à XmlHttpRequest par exemple), et je ne veux pas faire subire cela au utilisateurs(rices) : temps de réactions trop long, et ça couterait même chèr à qui est en connection RTC (il y en a encore qui le sont, oui).

Citation:

Envoyé par SpaceFrog

Il existe des tonnes de freeware pour chiffrer du code javascript...
http://www.google.fr/search?hl=fr&cl...eeware&spell=1

J'ai consulté la requête, mais ça ne donne rien de bon : aucun ne fonctionne. La plupart repose sur .NET, et je n'ai pas .NET (Windows98), et les seules à ne pas requérire .NET me jête une avalanche de messages d'erreur au premier démarrage, alors qu'aucun travail n'a même encore été demandé à l'application.

Citation:

Envoyé par SpaceFrog

Pour moi ça ne reste que du gadget très peu efficace

Je sais, il y en a beaucoup nargue le copyrigth sur le web, avec des arguments du genre « ils peuvent toujours rêver, ça nous empêchera pas de copier ». Mais disont que ça limite quand même un peu les dégats. De plus, je veux surtout limiter la possibilité de modifier du code, et pour cela, je pense qu'un bon brouillage peut faire l'affaire (empêcher la copie, je sais que c'est impossible).

Bref, je cherche toujours :( (si payant, alors pas plus de 5€... et pour quelque chose qui marche vraiment.. que je demande à pouvoir tester avant... parce que vu ce que j'ai vu jusque maintenant... ça crains)
29/06/2007, 08h28
SpaceFrog

copyright sur javascript ... faut pas rêver quand même ! :roll:

c'est comme deposer un brevet sur l'eau tiède :lol:
29/06/2007, 10h24
xk155

essayes ça : http://www.fckeditor.net/ckpackager

mais bon... pas convaincu que ça puisse éloigner les copieurs...

En plus c'est interressant de se faire copier et dépasser, ton script évoluera...
29/06/2007, 11h00
Taum

Citation:

(si payant, alors pas plus de 5€... et pour quelque chose qui marche vraiment.. que je demande à pouvoir tester avant... parce que vu ce que j'ai vu jusque maintenant... ça crains)

:yaisse2:

A ce compte là, fait le toi même ...
C'est pas si compliqué que ça en plus :roll:
29/06/2007, 11h10
SpaceFrog

je ne vois vraiment pas l'intérêt de chiffrer du javascript ...
et dépenser 5€ ou même gacher 30sec. de bande passant pour downloader une appli pour le faire ...
29/06/2007, 15h35
Hibou57

Citation:

Envoyé par xk155

essayes ça : http://www.fckeditor.net/ckpackager

Merciiii :D Je crois que ça correspond à ce que je voulais :) En plus ça compacte le code, ce qui m'arrange bien :)

Citation:

Envoyé par xk155

mais bon... pas convaincu que ça puisse éloigner les copieurs...

La copie, non, mais la modification oui. Et de toute façon, il y aura un élément final sur le serveur, sans lequel le programme JavaScript ne sera qu'à moitié utile. Ca me permettra au moins de gagner du temps.

Citation:

Envoyé par xk155

En plus c'est interressant de se faire copier et dépasser, ton script évoluera...

Là, je n'en suis pas trés sûre : évoluer ? Evoluer comment ? Comme toutes ces applications qui ne peuvent même plus se passer d'un énorme framework pour seulement afficher « bonjour » ? Evoluer pour être des puits à resources (ram et cpu) comme le sont toutes les applications que l'on voit maintenant ?

Je n'appel pas ça une évolution.

J'essais de faire en sorte que ce code fonctionne de manière fluide sur mon pc, qui est assez ancien, ce qui est pour moi une garantie de qualité, et aussi une garantie d'accessibilité... alors ce n'est pas pour laisser faire n'importe quoi avec ensuite et laisser tout abimer :(

Voilà une des raisons pour lesquelles je ne veux pas que ce soit modifier.

Citation:

Envoyé par SpaceFrog

copyright sur javascript ... faut pas rêver quand même !

c'est comme deposer un brevet sur l'eau tiède

Quel rapport avec l'eau tiède ?
Mais si tu veux par là que tout ce qui mal protégé, ou difficile à protégé, peut être légitimement volé, parce que c'est mal protégé, alors ça veut que si un soir en te promenant tu vois une maison avec la fenêtre ouverte, tu peux aller vider cette maison, et tu sera innocent pour la seule raison que la fenêtre était ouverte ? Ou ça veut dire que tu peux voler un sdf parce qu'il est faible et qu'il ne peut pas se défendre ?

Ca confirme que c'est la lois de jungle, et il n'y a pas de quoi en être fière.

Citation:

Envoyé par Taum

A ce compte là, fait le toi même ...
C'est pas si compliqué que ça en plus

C'est ce que disent tous les gens qui copient « il/elle peut le donner, c'est pas difficile »... et bien idem : au lieu de le copier, faites le vous-mêmes.

De plus, non, un brouilleur de code, ce n'est pas si évident qu'il y parraît, et j'estime que oui, ça peut bien valoir ses 5€, parce que ça ne se fait pas en 20 minutes, ni en 3h (sans compter les nombreux testes nécéssaire à la fiabilisation).

Merci encore à toi xk155 :D
29/06/2007, 15h40
SpaceFrog

en fait je voulais jsute dire que le javascript c'est un peu comme l'eau tiède et l'air que nous respirions... c'est à tout le monde ... un peu l'esprit de l'open source..

imagine que demain une société commerciale décide de mettre tout l'air en boite et de le vendre ...

T'as aussi vite fait de sécuriser toute la page en ne la mettant pas en ligne et en l'envoyant par courrier avec encre sympatique et faire payer le liquide révélateur 100€ le centilitre avec en plus autodestruction dans les 5 secondes ...
29/06/2007, 17h03
buzzkaido

Il y a aussi de l'idée dans ce post :

http://www.developpez.net/forums/sho...d.php?t=360845

Meme si ça n'avait rien a faire dans le forum windows et que je comprend absolument pas pourquoi des gens perdent du temps a vouloir proteger du javascript...

C'est un peu comme ecrire un livre et vouloir le vendre sans que les gens puissent le lire...
29/06/2007, 17h24
Hibou57

Citation:

Envoyé par buzzkaido

C'est un peu comme ecrire un livre et vouloir le vendre sans que les gens puissent le lire...

Avec le livre il y a l'obligation du respect du droit d'auteur : tu peux lire un livre (aprés que tu l'ai acheté dans une librairie), mais que tu l'ais acheté ne t'autorise pas à t'approprier les droit de l'auteur, ni même à te faire passer pour l'auteur, ni même à la copier sans son autorisation (il y a une taxe sur la photocopie dans ce sens), ni même à en modifier le contenu pour le faire passer pour le contenu original de l'auteur.

J'ai des tas de livre à la maison, en tous genre, je les ai acheté, je peux les lire librement. Je ne vois pas où est le problème d'appliquer le même principe à des programmes JavaScript. Ce n'est pas parce que ces livres étaient payant qu'il ne valent rien... et leur conenu a même beaucoup plus de valeurs à mes yeux, que celui de la presse gratuite ou des facicules gratuits qu'on peut trouver ça et là (dont je ne préfère même pas parler).

Le droit à la propriété et le garant de la pertinence de l'investissement personel, et il participe donc à une l'évolution des choses à avec patiences et maturité, ... au contraire du gratuit qui doit être developpé rapidement et à mondre cout, justement parce qu'il est gratuit (mais qui ne paient chèr par ailleurs, comme par exemple avec l'obligationd d'acheter un nouveau pc tout le temps pour faire fonctionner des applications de plus en plus mal conçues)

Citation:

Envoyé par SpaceFrog

T'as aussi vite fait de sécuriser toute la page en ne la mettant pas en ligne et en l'envoyant par courrier avec encre sympatique et faire payer le liquide révélateur 100€ le centilitre avec en plus autodestruction dans les 5 secondes ...

Trés second degré

Deux solutions.

Mais si je postais, c'était surtout pour dire que l'application indiqué dans un précédent post, de FCK éditor, ne fonctionne pas non-plus : elle requière .NET (quand je le disais... on ne peut-même plus lire et écrire un fichier texte sans .NET.... c'est ça le progrés... qui va dans le mauvais sens)

Mais j'ai remarqué une astuce : il ne faut pas chercher « javascript obfuscator », mais « javascript compressor ». Le première requête renvoie systèmatiquement des application ne fonctionnant qu'avec .NET (ça doit être une mode). La deuxième requête renvoie par contre des applications en ligne (dont le code est innacessible, car il est du coté serveur, mais ça ne les empêche pas d'être parfaitement utile, et sans que cela n'empêche que le code source puisse être probablement acheté pour qui y tiens avec raison).

Comme google n'est pas trés fiable, je préfère donner directement deux liens ici :

EDIT 30 juin 2007 -----
Les deux liens suivant, que je laisse pour raison d'historique, ne sont pas les plus fiables, bien qu'ils fonctionnent. Utilisez plutôt Dojo shrinksafe. Vois le post n° 20 de ce fil pour les détails.
FIN DE L'EDIT -----

JavaScript compressor from Edwards Dean
C'est celui que je préfère. Je suggère personnelement de cocher la case « Shrink variables » et de décocher la case « Base62 encode ». En effet, l'encodage nécéssite un décodage aprés le chargement du script, ce qui n'est pas une bonne chose pour la fluidité de l'application (et donc pas une bonne chose pour les utilisateurs/rices).

JavaScript compressor from javascriptcompressor.com
Un autre assez bon également, mais que j'aime moins que le précédent (mais ce qu'un avis subjectif). Pensez à cliquez sur « Advenced settings » pour quelques options supplémentaires.

Les deux fonctionnent bien, en plus ils compressent assez bien (le résultat peu faire un tier de l'original, ce qui n'est pas négligeable), je les ai testé et c'est ok... sauf mauvaises surprises... mais je touche du bois lol

Voilà :) Je peux enfin marqué ce fil comme « Résolu »... ce qui bien évidement ne ferme pas la discussion annexe qui est née de ce fil ;) (mais je vous laisse le soin de la poursuivre, je vous fais confiance pour ça).
29/06/2007, 17h30
buzzkaido

L'idée du post que j'indiquais en lien permet un autre type de protection :

Si l'utilisateur essaie d'acceder au fichier .js directement pour en voir le contenu, il recoit une page vide (ou avec ce que tu veux dedans) mais pas le vrai fichier .js

Celui-ci est uniquement chargé dans le navigateur et donc visible seulement avec un debuggeur.

Ce qui limite aussi fortement les possiblilté de voir ton code par un novice ou un programmeur pas super-motivé

Euh, j'oubliais de dire :

pour que ce soit vraiment efficace, il faut mettre l'ensemble de tout le javascript de ta page dans des .js chargés à part, le javascript "embarqué" dans la page reste visible.

Mais deja, le corps des fonctions est invisible...
29/06/2007, 17h37
Hibou57

Citation:

Envoyé par buzzkaido

L'idée du post que j'indiquais en lien permet un autre type de protection :

Si l'utilisateur essaie d'acceder au fichier .js directement pour en voir le contenu, il recoit une page vide (ou avec ce que tu veux dedans) mais pas le vrai fichier .js
[...]

Salut,

Tu pense peut-être à une protection qui teste le « referrer » qui charge le script ? J'y ai pensé, mais je sais d'expérience qu'il y au moins 10 à 15% des gens qui surfent en masquant leurs « referers ».

Mais je me trompe peut-être, je vais lire ton fil plus tard :)

Merci pour la suggestion
29/06/2007, 17h43
buzzkaido

Si si, c'est bien ça, le referer.

Les 10 ou 15% de gens qui ne pourront pas acceder à ton site a cause de ça seront surement les memes 10 ou 15% de gens qui achetent de la musique sur le Net, protégée par DRM et n'arrivent pas à l'ecouter sur leur auto-radio....

Protéger du contenu diffusé, c'est jamais facile !

Par contre, protéger un serveur l'est beaucoup plus : plus sûr, plus fiable, plus souple.
29/06/2007, 18h08
FremyCompany

Euh, désolé si tu ne sais pas lancer .NET sur ton ordinateur mais .NET est une avancée capitale de le monde du développement windows

Alors n'essaie pas de critiquer une technologie parce que tu n'a pas envie d'évoluer avec elle

Tant que tu y est, reste sous MS-DOS, ça permet aussi d'ouvrir un fichier texte et de l'éditer
__________________________________________
Crypter un fichier JavaScript, je peux comprendre la raison mais de toute façon, ca ne sert à rien du tout

1) Si on sait faire l'opération dans un sens, on sait la faire dans l'autre, du moins suffisamment bien pour re-rendre le fichier utilisable
2) L'idée du réferrer est très bonne mais figurez vous qu'il y a dans windows un dossier magique qu'on appelle "Temporary Internet Files", et dedans ce trouve tous les fichiers téléchargés par IE donc si IE accède au JS, forcément il se retrouvera dedans
3) Comme l'as dit SpaceFrog le JavaScript est un langage OPEN-SOURCE donc je ne vois pas quel est l'intérêt de le "crypter" ou autre
4) Un jour JavaScript sera compilé par les navigateurs, et plus interprété, et ce dans le but d'accélérer la vitesse de celui-ci. Qui dit compilateur dit aussi décompilateur...
30/06/2007, 00h15
DoubleU

Citation:

Citation:

Mais si je postais, c'était surtout pour dire que l'application indiqué dans un précédent post, de FCK éditor, ne fonctionne pas non-plus : elle requière .NET (quand je le disais... on ne peut-même plus lire et écrire un fichier texte sans .NET.... c'est ça le progrés... qui va dans le mauvais sens)

Citation:

Euh, désolé si tu ne sais pas lancer .NET sur ton ordinateur mais .NET est une avancée capitale de le monde du développement windows

Alors n'essaie pas de critiquer une technologie parce que tu n'a pas envie d'évoluer avec elle

Tant que tu y est, reste sous MS-DOS, ça permet aussi d'ouvrir un fichier texte et de l'éditer

Euh, pas besoin de tant d'agressivité hein. C'est pas parce que tu développes en .NET qu'il faut le faire passer pour ce qu'il n'est pas, capital.
La remarque de Hibou était la juste pour montrer que pour une opération aussi simple que brouiller un code, il faut installer tout le framework .NET . Je n'y vois personnellement pas de jugement de valeur, juste une simple constatation.
30/06/2007, 03h18
Hibou57

Citation:

Envoyé par DoubleU

La remarque de Hibou était la juste pour montrer que [...]

Merci DoubleU pour ta solidarité et ta remarque pertinante (je n'avais pas répondu, et puis en plus ça sortait du cadre de ce fil)

Si je repost, c'est pour un rectificatif (je vais corriger l'édit du premier post également). Les deux applications que j'indiquais posent parfois problèmes. J'ai été plus avant dans les testes, et surtout, j'ai testé le fonctionnement des fichier résultant.

Il s'avère qu'un seul est satisfaisant, et qu'il n'est pas dans ceux que j'ai donné. Le bon, s'appel Dojo Shrinksafe, et on peut y acceder ici :
-> Dojo shrinksafe

Il a tout de même un défaut (voir plus loin)

Il s'appel Shrinksafe a juste titre, parce qu'il évite de renomer les identificateur dont-il n'a pas la certitude qu'ils sont effectivement des identificateurs déclaré dans le fichier. Les deux autres au contraire m'on laissé de mauvaises surprises sur ce point, et renome des identificateur exporté depuis d'autres fichier par exemple, ce qui occasione des erreurs. Enfin, cela rend également plus fiable la compression ou le brouillage (c'est la même chose, techniquement parlant) des codes JavaScript qui contiennent les fameux racourcis à l'Internet Explorer pour les ID : vous savez... ce truc pas trés recommandé d'ailleur, qui vous fait faire <X id="xxx"> et puis ensuite xxx.style... = ... au lieu de faire document.getElementById ...

Il ne renomme pas les fonctions, donc on peut toujours exporté les fonctions d'un fichier compressé sans modifier les autres fichiers qui en dépendent. mais je pense à l'instant que j'au oublié de le vérifier pour les variable global (si je constate un soucis sur ce point, je repasserai pour le signaler).

Une compresseur nomé ESC, que j'ai testé également, n'est pas trés fiable non-plus, bien qu'il ait d'autres qualité (je ne donne pas d'URL, car la fiabilité et la priorité).

Dojo shrinksafe n'inspire pas tout à fait confiance de prime abord, parce que le site n'est pas trés soigné, et est, pour le moins, rustique. Mais je vous assure que la différence avec les autres se fait ressentire, et il mérite bien le qualificatif de Safe (pardon si j'ai l'air de faire de la pub, mais j'atteste sur l'honneur n'être associé à ce site en aucune manière :mrgreen: ).

Shrinksafe a tout de même un défaut, qui est à mon avis dut à la langue maternelle (l'anglais) de son/sa concepteur(rice) : il n'encode pas les caractère accentué dans les chaînes de caractère. Il faut donc écrire les chaîne de caractère avec des entité HTML, là où c'est nécéssaire (à moins qu'il n'y ait un hack, mais je l'ignore).

Conseils pour une compression ou un brouillage sans erreurs.

Pour que la compression se passe bien, il est conseillé que les sources JavaScript termine bien leurs instruction avec le ';' et même s'il y a un saut de ligne aprés l'instruction.

En d'autre terme, l'utilisation d'un compression/brouilleur, et aussi une bonne occasion de renouer avec de bonnes habitudes : encodé avec des entités HTML les caractères de chaînes qui le nécéssite, et terminé ses instruction avec ';' même quand cela est optionel, utilisé document.getElementById plutôt que les objets implicites propre à Internet Explorer, et j'ajouterais même, toujours déclaré ses variables explicitement et ne jamais se reposer sur la déclaration implicite.

Pour qu'un fichier JavaScript se compresse proprement sans introduire d'erreur, il faut donc qu'il soit bien codé (une belle occasion de rendre vos codes encore plus fiables et aussi plus portables)

Ces choses étant recommandé par ailleurs dans d'autres circonstances et pour d'autres raisons, vous ne pourrez qu'y gagner.

Avec mes excuses d'avoir préalablement donné deux mauvaises indications :oops: . Maintenant c'est corrigé :P et en avant la musique :D

P.S.

Citation:

Envoyé par buzzkaido

[...]Les 10 ou 15% de gens qui ne pourront pas acceder à ton site a cause de ça seront surement les memes 10 ou 15% de gens qui achetent de la musique sur le Net, protégée par DRM et n'arrivent pas à l'ecouter sur leur auto-radio....

Protéger du contenu diffusé, c'est jamais facile !
[...]

On peut acheter des mp3 sans DRM. Je connaissais un site pour ça, mais je l'ai perdu, si je le retrouve, je t'envoie un MP, et ceux/celles qui sont interessé(e)s, peuvent se faire connaître (raison de cette réponse publique). Le problème est que cette possibilité est assujetie au bon vouloir de l'éditeur(rice), et que le catalogue de MP3 (ou d'Ogg) sans DRM est plus restreint :( Au passage, noté que le problème avec les DRM (auxquels je suis opposés), va même encore plus loin que le problème de la compatibilité logicielle (ou logicielle sur le matérielle) et va même jusqu'à un problème géographique : j'ai un jour acheté un titre en MP3, pour l'offrire à une amie ( :oops: ) et c'était un titre qui n'était pas disponnible sans DRM. J'ai voulu bénéficier de la double clé, mais ça n'a pas put marché, parce qu'elle vie au Maroc, et moi en france. J'ai trouvé ça scandaleux et j'ai été vraiment triste.
30/06/2007, 11h59
FremyCompany

Bon désolé de m'être laissé emporté, mais il est vrai que .NET est une véritable avancée dans le monde du développement, et je trouve vraiment mal-venu de le critiquer... C'est un peu comme critiquer les fenêtres quand on est sous DOS... Sous DOS aussi on sait éditer un fichier texte, et on avait pas besoin de tout le FrameWork de windows pour ca ;)
Sans rancune aucune, mais veille à ne pas critiquer une technologie juste parce qu'elle ne tourne pas sur les anciennes machines ;)

_________________________________________
Pour ce qui est du cryptage de script, même si je ne suis pas pour, personnellement, je crois que tu peux demander à publier le résultat de tes recherches dans la FAQ JavaScript, ca pourrait aider d'autres gens qui cherchent à faire la même chose.

Pour ce qui est des raccourcis à ID, évite, ca risque de poser des problèmes ;) Par contre je suis de ton avis document.getElementById c'est long à écrire :( Certains FrameWork javascript implémentent une fonction pour gagner du temps : $(id)

Code:

function $(id) { return document.getElementById(id); }

Essaie, tu verras, tu vas l'adopter ;)
30/06/2007, 12h59
SpaceFrog

oui certaines librairies appoertent tout de même un confort d'utilisation
la librairie prototype http://dcabasson.developpez.com/arti...ototype-1.4.0/

également le window prototype avec les effets de scriptaculous
22/07/2007, 08h56
Hibou57

Un peu en marge de ce sujet, mais tout de même lié d'une certaine manière : je ne sais plus où, quelqu'un m'avais environ dit que plutôt que de brouiller le code javaScript pour le protéger contre les modifications ou autre, une meilleur idée serait peut-être de coder en Java plutôt qu'en JavaScript (il me semblait que c'était dans ce fil, mais je ne retrouve pas le post... est-ce que j'ai rêvé ou c'était bien ici ?).

Je viens de récuperer un JDK 1.1 (le plus basique), en pensant essayer de remplacer certains code javaScript par des applets Java. Mais apparement il n'est pas possible d'accéder au DOM de la page en Java. Donc les applications web basée sur DHTML sont contraintes d'utiliser JavaScript. Mais c'est dommage, parce que le Java aurait put y a gagner à avoir une classe d'accès au DOM HTML. Surtout que si JavaScript le fait, Java devrait en être capable (je parle du Java-1, et non pas des mamouths que sont les dernières versions).

Il ne me semble même pas possible non-plus de faire s'échanger des données entre une fonction JavaScript et une applet Java. Alors il n'y a même pas de pont envisageable.

Tant pis alors, j'aurais bien aimé pouvoir appliquer cette alternative, ... mais apparement, es impossibile
23/07/2007, 09h18
buzzkaido

Citation:

Surtout que si JavaScript le fait, Java devrait en être capable

Pour moi cette histoire me parait un peu bizarre...

Remplacer du javascript par du Java ?

L'un n'a STRICTEMENT RIEN à voir avec l'autre. Ni historiquement. Ni dans le langage lui-même. Ni rien du tout.

Le Javascript est un langage de script developpé pour le Web.

Le Java est un langage interpreté developpé afin de pouvoir concevoir des applications complexe tournant sur n'importe quelle machine physique dans les memes conditions grace à une machine virtuelle et en toute securité grâce à l'isolation de cette machine virtuelle para rapport à la machine physique.

Le Java n'a donc rien à voir avec le Web. Les applets ne sont qu'une facette de son utilisation.

Et pourquoi protéger du code javascript ? Il est à ce point incroyablement génial ? Un système de menu revolutionnaire ?
23/07/2007, 10h15
Hibou57

Alut Buzz ;) Toujours aussi fidèle à ce fil je vois :)

Citation:

Envoyé par buzzkaido

Le Java n'a donc rien à voir avec le Web. Les applets ne sont qu'une facette de son utilisation.

Oui, c'est des applet que je parlais, seulement des applets.

Citation:

Envoyé par buzzkaido

Et pourquoi protéger du code javascript ? Il est à ce point incroyablement génial ? Un système de menu revolutionnaire ?

Non, rien de révolutionnaire. Mais plusieurs raisons. La première est que je trouve JavaScript un peu pénible quand le volume de code devient important. Alors ça m'aurais fait plaisir : Java, c'est quand-même mieux structuré et plus fiable. Ensuite, l'autre raison, c'est la vitesse d'execution qui est meilleur en Java qu'en JavaScript. Pour le code, tu me demande pourquoi il devrait être caché : je peux te renvoyer la même question... pourquoi ne le serait-il obligatoirement pas. Comme je disais, c'est pour éviter les modifications non-désirée, et la copie bête et méchante. En plus, je pense que pour ouvrir un source, il faut qu'il soit sérieusement documenté. Et pour l'instant ce n'est pas le cas, et plutôt que d'ouvrir un source qui n'est pas mûre pour ça, je préfère encore le fermer.

C'est incroyable comme ça peut déranger de vouloir empêcher la copie... à croire qu'il y en a qui ne vivent que de ça ? C'est quand-même pas un drame non si on empêche la coipie d'un code ? Aprés tout, on a pas non-plus toujours directement accés au code des binaires compilé.

De toute façon, je pense qu'un code n'est jamais fait pour être modifier comme ça. Modifier un code, équivaut pour moi à la reformulation de son architecture, et je constate que les code ouvert que l'on voit ça-et-là sur le web, ne sont pas assez documenté pour le permettre. Alors je me pose des questions sur les réelles motivation : par jeux ? Par volonté d'appropriation ? Posseder pour posseder ? Ou autre choses ?

De toute façon, les applications ne sont pas conçues que pour les développeur... alors même si cette volonté de protection gêne les développeurs (on se demande bien pourquoi), je sais que par ailleurs et pour certaine catégorie d'application, les utilisateurs/developpeurs ne représentent qu'une petite part.

Que des gens qui travaillent ensemble sur un projet s'échnage leurs codes, c'est normal... mais que n'importe s'approprie le produit de n'importe qui, c'est une autre histoire.

Même s'il y a des exception : comme le fait d'avoir le code source d'une librairie fourni avec un compilateur par exemple. Là c'est ok, mais rien, toujours dans cette exemple, n'oblige à ouvrir le code du compilateur lui-même par exemple. Il faut que ce soit justifier par le nature du code. Sinon, comme je disais, s'il y a collaboration étroite, c'est différent... mais là, il faut bien sûre se mettre d'accord, et savoir où on va ensemble (la personne avec qui ont décide de travailler)

Voilà,
23/07/2007, 10h22
buzzkaido

Citation:

C'est incroyable comme ça peut déranger de vouloir empêcher la copie... à croire qu'il y en a qui ne vivent que de ça ?

C'est pas ça, mais bon, proteger le code C++ ou Java ou autre d'une application complete, bien sûr je suis pour dans la pluspart des cas.

Le code javascript n'est (en principe) qu'une faible partie du code d'une application Web. En general le code réélement interressant d'une telle appli est dans la partie serveur du code.

Et tout developpeur serieux preferera recoder le javascript plutot que d'utiliser du code qui vient d'on ne sait où, recupéré sur un site.

La question que je me pose n'est pas "Pourquoi proteger du code ?" mais plutot "Est-ce bien utile de dépenser du temps et de l'energie à proteger du javascript ?"
23/07/2007, 10h28
Hibou57

Citation:

Envoyé par buzzkaido

Le code javascript n'est (en principe) qu'une faible partie du code d'une application Web. En general le code réélement interressant d'une telle appli est dans la partie serveur du code.

Beh mon problème est justement là : même s'il y a une partie de le serveur, ce n'est qu'initiale et finale. Entre les deux, tout est entièrement en JavaScript. Mais bon, ça avance quand-même, et j'adapte (de toute façon, je veux quelque chose qui ne soit pas trop lourd)

Citation:

Envoyé par buzzkaido

Et tout developpeur serieux preferera recoder le javascript plutot que d'utiliser du code qui vient d'on ne sait où, recupéré sur un site.

Dans ce cas là, ça s'appel récupérer une information. Mais pour ça il y a mieux que les code : il y a des documentation de référence, les forums, etc. ;) Protéger un code ne signifie pas qu'on ne communique pas.

Citation:

Envoyé par buzzkaido

La question que je me pose n'est pas "Pourquoi proteger du code ?" mais plutot "Est-ce bien utile de dépenser du temps et de l'energie à proteger du javascript ?"

Oh non, rassure toi, je n'y dépense aucune energie, et je n'y passe pas une seule seconde. C'est surtout qu'il y a des avantages connexes : réduction de la taille du code avec l'obfuscation et meilleur structuration avec Java.

Si cela avait des impacts négatifs, je n'y penserai même pas, ou alors je le ferais tout autrement. D'ailleurs je n'ai même pas encore appliquer les solutions que je donnais dans ce fil à mes propres codes... c'est dire... (de toute façon, ce n'est pas encore terminer, et ça avance trop doucement... plein de petit trucs tatillon et de choses de ce genre)
23/07/2007, 10h58
buzzkaido

Ben dans les impacts négatifs, si tu compte utiliser Java :

- dépendance vis-a-vis de la présence sur le poste client d'un machine virtuelle java
- dépendance vis-a-vis de la Machine Virtuelle utilisée (Sun ou Microsoft)
- dépendance vis-a-vis de la version de Machine Virtuelle utilisée (Sun ou Microsoft)
- le navigateur doit accepter les applet

La principale contrainte dans tout ça est la premiere, evidemment, les autres sont en general OK.

Mais il y a aussi la gourmandise : une VM Java est relativement lourde.

Il y a peut-etre une autre alternative au Java : le flash.

Pour en avoir fait un peu, il me semble que tu peux acceder au DOM de la page, mais je suis pas sûr. Et c'est plus utilisé que les applets, donc en général plus souvent installé sur les postes clients.

Après, evidemment, ça depend si c'est pour une utilisation grand public ou en interne dans ta boite.

Tout ceci etant dit, pourquoi des boites comme Google ou Yahoo qui ne font pratiquement que du web ont developpé leurs API en javascript et pas en Java ou en Flash ?

Probablement pour une histoire de coût : les tests sont bien moins lourds en Javascripts, la technologie est maitrisée par beaucoup de monde, la fiabilité est presque à 100%, la compatibilité aussi...

Car quand Sun (ou autre)sort une nouvelle version de sa VM Java, en général pas de soucis, mais les incompatibilité arrivent... et là, c'est le drame !
23/07/2007, 11h09
Hibou57

Citation:

Envoyé par buzzkaido

Ben dans les impacts négatifs, si tu compte utiliser Java :

- dépendance vis-a-vis de la présence sur le poste client d'un machine virtuelle java
- dépendance vis-a-vis de la Machine Virtuelle utilisée (Sun ou Microsoft)
- dépendance vis-a-vis de la version de Machine Virtuelle utilisée (Sun ou Microsoft)
- le navigateur doit accepter les applet

La principale contrainte dans tout ça est la premiere, evidemment, les autres sont en general OK.

Le problème est aussi que la JVM n'est installé en standard qu'avec Windows98, et non pas avec Windows XP (parce que Microsoft avait quitté le projet de Sun entre temps). Rien que pour cette raison, j'ai décidé d'abandonner l'idée d'employer Java.

Citation:

Envoyé par buzzkaido

Mais il y a aussi la gourmandise : une VM Java est relativement lourde.

J'ai abordé involontairement cette qestion sur la section Java du forum... et là, j'ai été plutôt mal acceuilli... la question est apparement tabou. Alors j'ai eu un sourire aimable en te lisant écrire cela :D

Citation:

Envoyé par buzzkaido

Il y a peut-etre une autre alternative au Java : le flash.

Pour en avoir fait un peu, il me semble que tu peux acceder au DOM de la page, mais je suis pas sûr. Et c'est plus utilisé que les applets, donc en général plus souvent installé sur les postes clients.

Flash est désactivé sur beaucoup de poste également, donc ça ne me convient pas. Sans compter qu'il y a chez flash une course à la version que je n'aime pas (mais ce ne sont pas les seuls, c'est pareil avec java... à part que Java-1 reste un standard à part-entière, malgré les versions qui ont suivi)

Citation:

Envoyé par buzzkaido

Après, evidemment, ça depend si c'est pour une utilisation grand public ou en interne dans ta boite.

C'est pour du grand publique... je ne travail pas pour une boite, mais je travail seul (j'essai, je vais créer une appli qui aura une version gratuite et une version payant... c'est un coup d'essais)

Citation:

Envoyé par buzzkaido

Tout ceci etant dit, pourquoi des boites comme Google ou Yahoo qui ne font pratiquement que du web ont developpé leurs API en javascript et pas en Java ou en Flash ?

Pour ne pas perdre de client, c'est-à-dire pour des raisons d'accessibilité. Comme tu le souligne, la disponibilité de Java sur la machine hôte n'est pas garantie, ... et la disponibilité de flash est loin d'être aussi automatique qu'on ne le pense. Et même javascript est désactivé chez un nombre non-négligeable d'internaute (mais bon là, on ne peut rien faire, il n'y a pas d'alternative)

Citation:

Envoyé par buzzkaido

Probablement pour une histoire de coût : les tests sont bien moins lourds en Javascripts, la technologie est maitrisée par beaucoup de monde, la fiabilité est presque à 100%, la compatibilité aussi...

... peut-être pas de cout... mais pour éviter des pertes, oui, c'est sûre. Je ne pense pas que le cout des testes d'une application flash fasse peur à Google ;) c'est surement pas ça....

Citation:

Envoyé par buzzkaido

Car quand Sun (ou autre)sort une nouvelle version de sa VM Java, en général pas de soucis, mais les incompatibilité arrivent... et là, c'est le drame !

Oui, c'est pour ça que j'ai un faible pour les anciennes technologies, car plus stable et plus peireine.