Je ne suis pas sûr que quelqu'un d'autre ait répondu directement à votre question, à savoir que le code est affiché à partir de la commande View Source du navigateur.
Comme d'autres l'ont dit, il n'y a aucun moyen de protéger le javascript destiné à être exécuté dans un navigateur contre une visionneuse déterminée. Si le navigateur peut l'exécuter, toute personne déterminée peut également le visualiser/exécuter.
Mais, si vous placez votre javascript dans un fichier javascript externe qui est inclus avec :
<script type="text/javascript" src="http://mydomain.com/xxxx.js"></script>
le code javascript ne sera pas immédiatement visible avec la commande View Source - seule la balise script elle-même sera visible de cette façon. Cela ne veut pas dire que quelqu'un ne peut pas simplement charger ce fichier javascript externe pour le voir, mais vous avez demandé comment le garder hors de la commande View Source du navigateur et ceci le fera.
Si vous vouliez vraiment rendre la consultation de la source plus difficile, vous feriez tout ce qui suit :
- Mettez-le dans un fichier .js externe.
- Obfusquez le fichier de sorte que la plupart des noms de variables natives soient remplacés par des versions courtes, que tous les espaces blancs inutiles soient supprimés, qu'il ne puisse pas être lu sans traitement supplémentaire, etc...
- Incluez dynamiquement le fichier .js en ajoutant par programmation des balises script (comme le fait Google Analytics). Cela rendra encore plus difficile l'accès au code source à partir de la commande View Source, car il n'y aura pas de lien facile à cliquer.
- Mettez autant de logique intéressante que vous voulez protéger sur le serveur que vous récupérez via des appels ajax plutôt que d'effectuer un traitement local.
Cela dit, je pense que vous devriez vous concentrer sur les performances, la fiabilité et la qualité de votre application. Si vous devez absolument protéger un algorithme, mettez-le sur le serveur, mais à part cela, soyez compétitif en étant le meilleur dans votre domaine, pas en ayant des secrets. C'est finalement comme ça que le succès fonctionne sur le web de toute façon.
1 votes
Il est côté client et sera donc présent sur tous les clients (navigateurs).
8 votes
Pourquoi voudriez-vous cacher Javascript ? Ce n'est pas comme si vous y mettiez des données sensibles que vous ne voulez pas que l'utilisateur trouve... Pas vrai ? !
1 votes
Comment un navigateur peut-il savoir quel Javascript exécuter ?
1 votes
@PaulPRO a un bon point - pourquoi voudriez-vous cacher JavaScript ? Quiconque veut savoir ce que vous faites sera TOUJOURS capable d'obtenir votre script en quelques frappes. Ils ne se contenteront pas de compter sur View-Source. Toute personne qui ne sait pas comment obtenir un script ne s'y intéressera probablement pas de toute façon.
0 votes
stackoverflow.com/a/17468822/2450730
0 votes
@ Paulpro : Vous avez raison et tort à la fois. Si vous utilisez php/mysql et faites des appels ajax en utilisant la méthode GET, alors un pirate peut retrouver le fichier php à partir du code source de javascript/jquery et en utilisant DEV CONSOL, il peut envoyer un événement ajax avec des données GET avec un contenu malveillant qui peut tout gâcher dans la base de données mysql.
0 votes
Pourquoi ne pouvez-vous pas mettre à l'intérieur de l'étiquette de toile. ?
0 votes
Utiliser Encode.js : encodejs.devincity.com
1 votes
@UdayHiwarale C'est très Il est facile de voir quelles sont les requêtes GET et autres requêtes HTTP effectuées par le client (il suffit d'ouvrir la console de développement et d'aller dans l'onglet réseau). Lorsque vous développez un site Web, vous devez partir du principe que toutes les requêtes sont falsifiées par un attaquant. Vous devez donc valider toutes les données et échapper soigneusement chaque chaîne de caractères que vous insérez dans du code SQL ou autre.
0 votes
C'est en effet possible, grâce à une méthode relativement simple. Voir ma réponse à ce fil de discussion : stackoverflow.com/questions/6335644/
0 votes
Les fichiers PHP sont secrets car ils s'exécutent sur le serveur, et même les messages d'erreur et le débogage sont sous le contrôle du développeur. Une solution secrète similaire pour les fichiers JS et CSS semble être très difficile, et pourrait nécessiter l'aide des navigateurs.