salut, je voudrais cacher du code javascript , comme les controle validators de ASP.NET
le truc c'est que j'emploie des expressions regulieres directement extraites de mes objets PHP, et que les laisser a vue des internautes pourrait constituer une faille.
 
J'avais fait un truc du genre :
 

le principe etait de créer une variable de session qui serait détectée dans le fichier javascript.php puis détruit a la fin de son execution de sorte qu'un tentative sans variable de session se hurte a un die();
 
mais ca ne marche pas avec notre cher mozilla qui reparcours la page pour afficher les sources.. Avez vous des idées ?

euh...
 
ta page "principale" crée une session avec "dtc.com" en valeur.
ta page de script regarde si y'a "dtc.com" en valeur.
si oui, elle affiche, et shoot la valeur de session.
comme ça, si on réaffiche que le JS, proutch.
 
ensuite, dans les header HTTP, tu forces pragma: no-cache et tout le tralala pour obliger le nav ou tout recharger etne pas utiliser une valeur en cache.
 
ceci dit...
 
tu ouvres le temp files de IE, tu trouveras dans tous les cas le fichier tel qu'il a été utilisé par IE... même si tu interdits la mise en cache...

ok, c'est le header qu'il me manquait mais avec firefox, je doute que ca marche, car il semble recharger toute la page...

je sais pas, je vois pas comment tu fais pour voir la source du JS avec Moz depuis la page appelante. moi je vais copy-paste de l'url du js dans moz... y'a un autre moyen ?

mais ton fichier js il va quand même se retrouver dans les "tempory files" et donc être récupérable par celui "qui veut vraiment" non?
edit: over-over-over burned ... j'ai un peu trainé

nan => no-cache

Si on pousse le raisonnement plus loin, ton développement est problématique : à partir du moment où tu sers le fichier en HTTP, le client le verra (et pourra en afficher le contenu), quelle que soit la protection que tu mets en place (cache ou pas cache, variable de session ou pas variable de session, temporary files ou pas). Donc la faille est déjà présente.
Si ton information est critique pour la sécurité de ton site, elle ne doit pas être affichée en HTTP (HTTPS ne résoud pas le problème), et ne doit pas sortir de ton serveur.
 
Si tu dois valider l'entrée de tes formulaires, cela doit être fait sur le serveur de toutes façons (la validation en JS est complémentaire, et ne doit être vue que comme une aide à l'internaute).
 
(Pour ceux que ça intéresse, voici deux outils qui permettent de sniffer le traffic HTTP : TraceWeb, Ethereal. Il y en a d'autres)

la validation d'un formulaire doit toujours se faire coté serveur  
 
en effet , dans le cas de verification js, que se passe t il si l'utilisateur a desactivé js, ou si il a une vielle version bugguée ?  

Il y a une possibilité de + ou - cacher le code mais bon. C'est de placer le code js dans un fichier php et lors de l'appelle de ce fichier.
<script language="javascript" type="text/javascript" src="js.php?dtc=<?  echo time() ?>">
 
Dans le fichier dtc.php tu places une condition.  
if($_GET['dtc'] = time()) //Attention il faut placer une plage de tolérance de 5 secondes environs.
 
Mais bon ça reste une technique de chien malade qui n'est pas fiable ça va peut etre bluser un blaireau .
Mais pour le principale je suis daccord avec FLO850 . Les test se font du coté serveur. Ne jamais faire confiance au entré entrant.

je parle d'experience
sur un de mes sites , jai fait confiance au js ( demande du client ) et il y a eu pas mal de soucis avec un petit malin qui à désactivé js  
donc maintenant, dans cette situation ,je fais une double validation : une en JS ( si le client le veut ) et une en php (pas besoin de présentation, de mise en page, juste un message d'avertissement 'erreur sur la saisie' )

ça n'empêche pas que les navigateurs copient le fichier sur le disque. no-cache indique juste qu'ils ne doivent pas le réutiliser ensuite.

généralement, ce qu'on fait c'est :
-> js : contrôles basiques, genre vérification de la syntaxe de saisie
-> serveur : contrôles avancés (vérification de l'intégrité des données, validations, etc.)
-> js (back) : mise en forme du message d'erreur en fonction du contrôle JS ou du contrôle serveur

Je suis assez daccord avec toi, il ne faut pas complétement banire le JS dans la gestion des contrôles afin d'éviter de saouler l'internaute avec les recharges de page, par exemple, mais toujours faire un contrôle coté serveur poussé.
Et flo à fait la cruel expérience (indépendante de sa volonté) de ce que ça peut coûte de faire les contrôles coté client.
Personnellement, je fais les contrôles à la demande du javascript coté client via AJAX et lorsque c'est posté il fait appelle au même fonction utilisé par ajax pour faire les contrôles.