Log:
les _DIR_xx se referent tous au repertoire courant (racine ou ecrire/), adopter une convention differente pour _DIR_JAVASCRIPT est confusionnant et casse de plus la compatibilite pour rien
a commencer par la formulaire de login qui envoyait le pass en clair depuis [11169]
on ajoute la constante _JAVASCRIPT qui reference le sous dossier javascript/ et peut etre utilisee dans les find_in_path et les #CHEMIN
Du fait de la faille de securite presente dans [11169] et plus, il est vivement conseille d'upgrader a cette version mini.
Log:
les _DIR_xx se referent tous au repertoire courant (racine ou ecrire/), adopter une convention differente pour _DIR_JAVASCRIPT est confusionnant et casse de plus la compatibilite pour rien
a commencer par la formulaire de login qui envoyait le pass en clair depuis [11169]
on ajoute la constante _JAVASCRIPT qui reference le sous dossier javascript/ et peut etre utilisee dans les find_in_path et les #CHEMIN
ok, j'avais hésité sur cette histoire de nom, c'est mieux de garder la compatibilité de "_DIR_JAVASCRIPT", mais il vaudrait mieux alors prendre NOM_JAVASCRIPT que "JAVASCRIPT" pour être homogêne avec les autres constantes.
Maintenant j'aimerais que tu expliques pourquoi le fait de changer le nom d'une constante peut amener un trou de sécurité.
Log:
les _DIR_xx se referent tous au repertoire courant (racine ou ecrire/), adopter une convention differente pour _DIR_JAVASCRIPT est confusionnant et casse de plus la compatibilite pour rien
a commencer par la formulaire de login qui envoyait le pass en clair depuis [11169]
on ajoute la constante _JAVASCRIPT qui reference le sous dossier javascript/ et peut etre utilisee dans les find_in_path et les #CHEMIN
ok, j'avais hésité sur cette histoire de nom, c'est mieux de garder la compatibilité de "_DIR_JAVASCRIPT", mais il vaudrait mieux alors prendre NOM_JAVASCRIPT que "JAVASCRIPT" pour être homogêne avec les autres constantes.
si tu veux, pas de probleme pour moi
Maintenant j'aimerais que tu expliques pourquoi le fait de changer le nom d'une constante peut amener un trou de sécurité.
<script src='#EVAL{_DIR_JAVASCRIPT}/md5.js'></script>
renvoyait une url fausse dans le formulaire de login
donc md5.js n'etait pas chargée
et le mot de passe circulait en clair entre client et serveur au lieu d'etre hashé avec l'aléa.
Meme si on avait modifié le formulaire de login de la dist, cela entrainait le probleme sur tous les formulaires de login personalisés dans la nature, ce qui est embetant tout de meme.
Le 12 févr. 08 à 17:08, cedric.morin@yterium.com a écrit :
Maintenant j'aimerais que tu expliques pourquoi le fait de changer le nom d'une constante peut amener un trou de sécurité.
<script src='#EVAL{_DIR_JAVASCRIPT}/md5.js'></script>
renvoyait une url fausse dans le formulaire de login
Ah zut, je ne me ferai jamais à ce Eval qui fait que les modifs de programmation ne concernent pas que ecrire/, je plaide coupable. Cela dit, je n'appelle pas ça un trou de sécurité: 99% des internautes relèvent leur courrier avec POP, où le mot de passe circule en clair. C'est plutot une qualité de service inférieure à celle annoncée.
donc md5.js n'etait pas chargée et le mot de passe circulait en clair
Là, c'est tout de même ennuyeux de ne pas avoir du code qui dise "si le cryptage n'est pas possible, je me rabats sur la stratégie sans javascript", parce qu'il suffit que ce fichier devienne inaccessible, quelle qu'en soit la raison, pour que le pb se pose à nouveau, c'est trop fragile.
Mais à quelque chose malheur est bon: tu viens implicitement de fermer le ticket 984. Go !
Le 12 févr. 08 à 17:08, cedric.morin@yterium.com a écrit :
Maintenant j'aimerais que tu expliques pourquoi le fait de changer le nom d'une constante peut amener un trou de sécurité.
<script src='#EVAL{_DIR_JAVASCRIPT}/md5.js'></script>
renvoyait une url fausse dans le formulaire de login
Ah zut, je ne me ferai jamais à ce Eval qui fait que les modifs de programmation ne concernent pas que ecrire/, je plaide coupable. Cela dit, je n'appelle pas ça un trou de sécurité: 99% des internautes relèvent leur courrier avec POP, où le mot de passe circule en clair. C'est plutot une qualité de service inférieure à celle annoncée.
Oui ca n'est pas un trou direct, mais un abaissement du niveau de sécurité qui rend possible une attaque qui ne l'est pas en principe.
donc md5.js n'etait pas chargée et le mot de passe circulait en clair
Là, c'est tout de même ennuyeux de ne pas avoir du code qui dise "si le cryptage n'est pas possible, je me rabats sur la stratégie sans javascript", parce qu'il suffit que ce fichier devienne inaccessible, quelle qu'en soit la raison, pour que le pb se pose à nouveau, c'est trop fragile.
Oui mais c'est le cas, si on a pas de javascript on ne sait pas faire mieux que d'envoyer le passe en clair, sauf à implémenter un https
Mais à quelque chose malheur est bon: tu viens implicitement de fermer le ticket 984. Go !