ça parait plus clair ,
je ne fais pas de fixation sur la fonction eval ,
mais tronquer un langage de ses fonctions alors que c'est lui qui permet
d'améliorer la sécurité à la source c'est pas raisonnable
je n'ai pas analysé complètement le comportement en cas d'erreur ,
il y a des cas ou il abandonne le script complètement d'autres où il
passe à la ligne suivante
( je n'en ai pas vu ou il passe à l'instruction suivante sur la même
ligne )
il faudrait être sùr de pouvoir analyser tous les cas possibles ,
lors d'une modification on sait bien qu'il peut y avoir des répercussions
ça parait plus clair ,
je ne fais pas de fixation sur la fonction eval ,
mais tronquer un langage de ses fonctions alors que c'est lui qui permet
d'améliorer la sécurité à la source c'est pas raisonnable
je n'ai pas analysé complètement le comportement en cas d'erreur ,
il y a des cas ou il abandonne le script complètement d'autres où il
passe à la ligne suivante
( je n'en ai pas vu ou il passe à l'instruction suivante sur la même
ligne )
il faudrait être sùr de pouvoir analyser tous les cas possibles ,
lors d'une modification on sait bien qu'il peut y avoir des répercussions
ça parait plus clair ,
je ne fais pas de fixation sur la fonction eval ,
mais tronquer un langage de ses fonctions alors que c'est lui qui permet
d'améliorer la sécurité à la source c'est pas raisonnable
je n'ai pas analysé complètement le comportement en cas d'erreur ,
il y a des cas ou il abandonne le script complètement d'autres où il
passe à la ligne suivante
( je n'en ai pas vu ou il passe à l'instruction suivante sur la même
ligne )
il faudrait être sùr de pouvoir analyser tous les cas possibles ,
lors d'une modification on sait bien qu'il peut y avoir des répercussions
On 07/24/11 00:05, mb wrote:
> mais quand vous écrivez ( ne chipotez pas sur la syntaxe svp )
> que croyez vous que fait l'interprète javascript sur un
> onClick="texte"; ?
> eval(texte)
Ben nom (ter)
> je ne fais que reprendre votre affirmation
> et elle est fausse , javascript est interprété et donc ne change pas le
> texte en code , il interprète le texte ( un peu comme la version switch
> dont on parlait )
Cest là que tu as tout faux. Les moteurs JS *compilent* le Javascript
en bytecode, et le mettent en cache.
Tiens, ça me rappelle un guignol qui soutenait que les buffer
overflow ne sont pas liés à des problème de sécurité puisque ce sont des
erreurs de programmation.
Les erreurs de programmations mènent systématiquement à des problèmes
de sécurité.
On 07/24/11 00:05, mb wrote:
> mais quand vous écrivez ( ne chipotez pas sur la syntaxe svp )
> que croyez vous que fait l'interprète javascript sur un
> onClick="texte"; ?
> eval(texte)
Ben nom (ter)
> je ne fais que reprendre votre affirmation
> et elle est fausse , javascript est interprété et donc ne change pas le
> texte en code , il interprète le texte ( un peu comme la version switch
> dont on parlait )
Cest là que tu as tout faux. Les moteurs JS *compilent* le Javascript
en bytecode, et le mettent en cache.
Tiens, ça me rappelle un guignol qui soutenait que les buffer
overflow ne sont pas liés à des problème de sécurité puisque ce sont des
erreurs de programmation.
Les erreurs de programmations mènent systématiquement à des problèmes
de sécurité.
On 07/24/11 00:05, mb wrote:
> mais quand vous écrivez ( ne chipotez pas sur la syntaxe svp )
> que croyez vous que fait l'interprète javascript sur un
> onClick="texte"; ?
> eval(texte)
Ben nom (ter)
> je ne fais que reprendre votre affirmation
> et elle est fausse , javascript est interprété et donc ne change pas le
> texte en code , il interprète le texte ( un peu comme la version switch
> dont on parlait )
Cest là que tu as tout faux. Les moteurs JS *compilent* le Javascript
en bytecode, et le mettent en cache.
Tiens, ça me rappelle un guignol qui soutenait que les buffer
overflow ne sont pas liés à des problème de sécurité puisque ce sont des
erreurs de programmation.
Les erreurs de programmations mènent systématiquement à des problèmes
de sécurité.
On 07/22/11 10:17, mb wrote:
> donc il faut être certain de tout savoir avant de se lancer à écrire
> quelque chose ?
Non, mais raconter n'importe quoi et le soutenir est plus gênant. Le
développement Web cest compliqué, demande beaucoup d'expertise et
surtout de prudence. Si tu crois le contraire, abandonne de suite.
On 07/22/11 10:17, mb wrote:
> donc il faut être certain de tout savoir avant de se lancer à écrire
> quelque chose ?
Non, mais raconter n'importe quoi et le soutenir est plus gênant. Le
développement Web cest compliqué, demande beaucoup d'expertise et
surtout de prudence. Si tu crois le contraire, abandonne de suite.
On 07/22/11 10:17, mb wrote:
> donc il faut être certain de tout savoir avant de se lancer à écrire
> quelque chose ?
Non, mais raconter n'importe quoi et le soutenir est plus gênant. Le
développement Web cest compliqué, demande beaucoup d'expertise et
surtout de prudence. Si tu crois le contraire, abandonne de suite.
On 07/23/11 02:26, mb wrote:
> ça parait plus clair ,
> je ne fais pas de fixation sur la fonction eval ,
> mais tronquer un langage de ses fonctions alors que c'est lui qui permet
> d'améliorer la sécurité à la source c'est pas raisonnable
Bannir les fonctionnalités et les habitudes qui mènent à des erreurs
et une bonne pratique, que ce soit en matière de sécurité qu'en matière
de gestion de projet. Lorsqu'on utilise un language, une technologie, il
faut l'utiliser dans les limites de ces connaissances, et n'utiliser que
ce qu'on est certain de pouvoir maîtriser. Sinon tu vas au devant de
profonds problèmes.
On 07/23/11 02:26, mb wrote:
> ça parait plus clair ,
> je ne fais pas de fixation sur la fonction eval ,
> mais tronquer un langage de ses fonctions alors que c'est lui qui permet
> d'améliorer la sécurité à la source c'est pas raisonnable
Bannir les fonctionnalités et les habitudes qui mènent à des erreurs
et une bonne pratique, que ce soit en matière de sécurité qu'en matière
de gestion de projet. Lorsqu'on utilise un language, une technologie, il
faut l'utiliser dans les limites de ces connaissances, et n'utiliser que
ce qu'on est certain de pouvoir maîtriser. Sinon tu vas au devant de
profonds problèmes.
On 07/23/11 02:26, mb wrote:
> ça parait plus clair ,
> je ne fais pas de fixation sur la fonction eval ,
> mais tronquer un langage de ses fonctions alors que c'est lui qui permet
> d'améliorer la sécurité à la source c'est pas raisonnable
Bannir les fonctionnalités et les habitudes qui mènent à des erreurs
et une bonne pratique, que ce soit en matière de sécurité qu'en matière
de gestion de projet. Lorsqu'on utilise un language, une technologie, il
faut l'utiliser dans les limites de ces connaissances, et n'utiliser que
ce qu'on est certain de pouvoir maîtriser. Sinon tu vas au devant de
profonds problèmes.
Hahaha. Ce n'est pas toujours facile, mais si tu introduis la chaîne
suivante dans la variable nom :
Hahaha. Ce n'est pas toujours facile, mais si tu introduis la chaîne
suivante dans la variable nom :
Hahaha. Ce n'est pas toujours facile, mais si tu introduis la chaîne
suivante dans la variable nom :
pour pouvoir compiler du code javascript il va être obligé de
l'interpréter d'une façon ou d'une autre , il y a peut-être un gain pour
les appels à partir du html car le texte est "fixe"
mais en cas d'appel à eval ou une indirection comme
innerHTML="..."
ou un "javascript:texte"
pourquoi le compiler ( avec un passage par interprétation ) d'abord et
ensuite l'exécuter ? il me semble qu'il y a perte de temps
et je doute qu'ils aient fait ça
j'apprécie que le guignol ne soit pas moi !
si on pousse un peu plus loin
les fautes de frappes
les orages
le chat qui marche sur le clavier
pour pouvoir compiler du code javascript il va être obligé de
l'interpréter d'une façon ou d'une autre , il y a peut-être un gain pour
les appels à partir du html car le texte est "fixe"
mais en cas d'appel à eval ou une indirection comme
innerHTML="..."
ou un "javascript:texte"
pourquoi le compiler ( avec un passage par interprétation ) d'abord et
ensuite l'exécuter ? il me semble qu'il y a perte de temps
et je doute qu'ils aient fait ça
j'apprécie que le guignol ne soit pas moi !
si on pousse un peu plus loin
les fautes de frappes
les orages
le chat qui marche sur le clavier
pour pouvoir compiler du code javascript il va être obligé de
l'interpréter d'une façon ou d'une autre , il y a peut-être un gain pour
les appels à partir du html car le texte est "fixe"
mais en cas d'appel à eval ou une indirection comme
innerHTML="..."
ou un "javascript:texte"
pourquoi le compiler ( avec un passage par interprétation ) d'abord et
ensuite l'exécuter ? il me semble qu'il y a perte de temps
et je doute qu'ils aient fait ça
j'apprécie que le guignol ne soit pas moi !
si on pousse un peu plus loin
les fautes de frappes
les orages
le chat qui marche sur le clavier
certes
il faut aussi faire confiance à ceux qui ont écrit js et sa fonction eval
qui sont eux aussi des pro et probablement des meilleurs
certes
il faut aussi faire confiance à ceux qui ont écrit js et sa fonction eval
qui sont eux aussi des pro et probablement des meilleurs
certes
il faut aussi faire confiance à ceux qui ont écrit js et sa fonction eval
qui sont eux aussi des pro et probablement des meilleurs
je ne le crois pas
mais qui peut être sûr qu'après des expertises par des pro qui peuvent
être de niveaux différents , il ne reste pas de fautes dangereuses ?
vous claquez la porte au nez de tous les amateurs et dévelopeurs
débutants , c'est du mépris ?
clamer sur tous les toits que js est dangereux
c'est la meilleure solution pour faire peur à tous le monde
et pousser les gens à "débrancher" leur js et se retrouver avec des
sites statiques ( mais pas forcément inintérressant )
mais ils continue à utiliser des formes , des jeux dont on ne sait pas
trop ce qu'ils chargent ...
et pour aller un peu plus loin , qui dit qu'un bug
dans un lecteur de news ne va pas provoquer des catastrophes ?
n'y-a-t-il pas de compromis à trouver entre
ne rien vérifier ( inacceptable )
et tout vérifier ( impossible ) ?
je ne le crois pas
mais qui peut être sûr qu'après des expertises par des pro qui peuvent
être de niveaux différents , il ne reste pas de fautes dangereuses ?
vous claquez la porte au nez de tous les amateurs et dévelopeurs
débutants , c'est du mépris ?
clamer sur tous les toits que js est dangereux
c'est la meilleure solution pour faire peur à tous le monde
et pousser les gens à "débrancher" leur js et se retrouver avec des
sites statiques ( mais pas forcément inintérressant )
mais ils continue à utiliser des formes , des jeux dont on ne sait pas
trop ce qu'ils chargent ...
et pour aller un peu plus loin , qui dit qu'un bug
dans un lecteur de news ne va pas provoquer des catastrophes ?
n'y-a-t-il pas de compromis à trouver entre
ne rien vérifier ( inacceptable )
et tout vérifier ( impossible ) ?
je ne le crois pas
mais qui peut être sûr qu'après des expertises par des pro qui peuvent
être de niveaux différents , il ne reste pas de fautes dangereuses ?
vous claquez la porte au nez de tous les amateurs et dévelopeurs
débutants , c'est du mépris ?
clamer sur tous les toits que js est dangereux
c'est la meilleure solution pour faire peur à tous le monde
et pousser les gens à "débrancher" leur js et se retrouver avec des
sites statiques ( mais pas forcément inintérressant )
mais ils continue à utiliser des formes , des jeux dont on ne sait pas
trop ce qu'ils chargent ...
et pour aller un peu plus loin , qui dit qu'un bug
dans un lecteur de news ne va pas provoquer des catastrophes ?
n'y-a-t-il pas de compromis à trouver entre
ne rien vérifier ( inacceptable )
et tout vérifier ( impossible ) ?
