My understanding was that only the javascript code placed inline in the HTML page would show, never the code stored in .js files
...and I had never seen in any browser code in a .js file show on the clientside...
until I started to use Chrome and noticed all my code is available for viewing???
Have I been convincing myself the code is safe in .js files, when in fact it never was?
and while on this subject can a responder be totally clear whether the code in .js files can be hidden or not.
I have read many posts that left me doubting whether it can be done or not.
. Some say to place it in a .js file on the server so it executes on the server...
--- using 'language=javascript' and an html line with 'runat server'? no idea how to do that.
--- But, would that not defeat the purpose of speed, and refresh since the server has to be accessed?
--- might as well code it in the code-behind???(C#, VB, php, ...)
. Some say use an AJAX call etc... but it seems others contradict that, saying the code lands on the clientside anyway thus will show? ...and I am assuming this would be a callback with no page redraw...
JavaScript is executed in the browser, this means the script has to be submitted to the client. So, of course anyone can view the code, wether it's happening in the developer tools, getting the direct link out of your html or, for example, using a http sniffer.
Altough, there are some methods to make the script unreadable for humans.
Minifying your script is a good practice in general. It decreases file-size, so the client has to download less, speeding up loading time. After all, this does not really help making your script "unreadable" for users, there are a lot of deminifying services all around the web.
Still, there is another way: obscurifying (or obfuscate) your script. This replaces the code to make it unreadable. Unfortunately, I don't really have experience with using this technique, so I don't know how it would affect the performance of the js-code.
Maybe you want to have a look at this: How can I obfuscate (protect) JavaScript?
Javascript code can be seen even if its in a .js file the only thing you can do to make it little tough to understand is minify the js file.
Actually, javascript code stored in a separated file wont be shown directly; the user must explicitly type the name of the file in the address bar to see its content.
The only way to hide it is, as said before, to minify the file, which compress the file and make it unreadable for humans.
Related
I am trying to reverse engineer some javascript code and am struggling to see how things are working.
In order to get a better feel for this I would like to add some console.log() statements and watch a few variables so that I could see what is going on as the code gets executed.
Is there a way to force my page locally to load javascript from my box instead of from the externally hosted site? I essentially want to modify the script and load my modified version when this external page tries to call whatever functions it needs to go through.
I was thinking maybe modify the hosts file so that when my browser goes to look for the external site it redirects to some kind of internal host? I am not quite sure exactly how to do it. If someone could point me in the right direction I would really appreciate it.
Thanks!
I have searched the following and it seems no one evan asks about, so I assume there is something facepalm dumb about it:
In a php file
... php code
?><script type="text/javascript> <?php include js/filename.js ?></script>
<?php
... php code
It seems what you're trying to do is bundle your JS into your HTML output. There are in fact several use cases for this, but they don't come up often. For example, I had a web application that would load on game consoles which had no cache. As a micro-optimization, I'd just bundle all the scripts and CSS into the HTML to reduce the number of HTTP requests.
Generally speaking though, there are downsides to this. Suppose you want to use that same JavaScript on multiple pages. Where the script could have been loaded on Page A, cached, and then immediately available for Page B, now you have to load the whole thing again for Page B. Also, don't forget that proxy servers cache static resources well. If you're creating pages dynamically, those probably aren't going to be cached, even though the JavaScript could be.
Now, onto the bundling technique... what you're doing is facepalm indeed. By using include(), you're telling PHP to execute the contents of that file as if it were PHP. That's not a PHP file (I assume anyway), that's JavaScript. It's unlikely, but if <?php were to end up in that file, you're going to end up executing code you didn't intend to execute server-side. What's worse is that you're wasting CPU by having PHP look for its tokens. readfile() is what you'd want instead, which would pass through the contents of that file.
Other things to be aware of are escaping and such. You're now using a plain JS file in the context of HTML. Caution is needed.
Best to use an existing bundler tool for this. I don't have any specific recommendations at the moment... I haven't found one in PHP I particularly like.
i have seen answers to similar questions. but, not quite what i want to know. if i make an external javascript file. then, on the client side, when the client loads the HTML, all they see is a link to the external javascript file. like this:
<script src="myScript.js"></script>
they never see the source code.
i don't get all this talk about obfuscation & minification. best way is just make an external file. then, without hacking into the server to download the source, they will only get machine code.
They can still follow the link to get the file directly.
Just display the source of this (this question) page, you can see
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
but you can still simply open https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js to see the source.
Even obfuscation doesn't provide protection as the source is still accessible to the client and he can de-obfuscate it (although that can be hard, it is not impossible).
And minification is used to reduce file size, so the file loads faster (and thus the page load time is lower).
i get it now. but, someone answered that you can hide the source w/PHP server side produced web pages. i haven't understood this yet. but, i have seen this answer a few times. this would seem the way to hide your scripts.
I understand that scripting language such as PHP will not be shown in the page source of the browsers. Is it not the same for JavaScript?
If so, why are they treated differently and are there solutions available to hide JavaScript from page source (revealed by browser)?
I don't need the details about how exactly to hide it, just out of my curiosity if it has been worked on.
Thanks!
PHP is run on the server and produces some output, often HTML, but may also include XML, CSS, PHP, images etc.
JS gets sent to the client, and is run there, so they need to see it.
You can always view JS source, though you can obfuscate it. There isn't much point though, as a decent debugger will let you work things out anyway.
For instance, using the Web Inspector in Webkit browsers, or Firebug will allow you to view the javascript and set breakpoints and see variable values, so it's often trivial to work out what is going on.
This is OK though, and it one of the reasons why learning JS is so straight forward. When designed correctly, it's rare that this presents a security problem.
You may find sites where the JS looks mangled and unreadable - this is frequently done to reduce the file size, hence all the .min.js files you see on websites rather than to make it hard to read.
Most people do this automatically as part of their build process, rather than doing it by hand. To do this, https://github.com/mishoo/UglifyJS is a good choice.
You should understand that there are server-side and client-side scripting languages. What you see on the client (browser) is the output of execution of the server-side script (PHP, Perl etc).
That said, there have been libraries developed to obfuscate JavaScript code.
PHP isn't "shown" in the browser because it's not there: it's already been rendered as HTML and sent to the browser by the server. (Same as Java servlet or JSP code.)
In-line JavaScript is part of what's sent to the browser, so it can be shown in page source.
JavaScript source linked in a <script> tag is not shown as part of page source; you only see the tag and the URL.
I understand that scripting language such as PHP will not be shown in
the page source of the browsers. Is it not the same for JavaScript?
Yes, server-side script is not visible in the browser's source though client-script like
JavaScript is fed to and parsed by the browser.
If so, why are they treated differently and are there solutions available to hide JavaScript from page source (revealed by browser)?
"Hiding" JavaScript isn't possible. Though, you can minify and obfuscate the script.
http://en.wikipedia.org/wiki/Minification_(programming)
http://en.wikipedia.org/wiki/Obfuscation
No, you need to distinguish between serverside and clientside (scripting) languages.
A serverside script runs invisible [from the client] and sends its results (of any type, including js files) to the browser. These result files are public.
A browser receives public files. Some of them can and will be executed. As JavaScript is a non-compiling language, you will always see its source.
See also How to prevent View Source of page using Javascript?, how to hide javascript code etc. - you only can obfuscate it.
Javascript and PHP are two different concepts one of them is client side language which can be seen in browser and the other server side which is hidden to the eye.
One simple way to hide your javascript code would be to include in a file so it wouldn't be seen in that specific page - but everyone will have a link to it and can still see it when they click on it.
Other solution would be to minify it, which would work the same but is going to be petty much unreadable.
http://en.wikipedia.org/wiki/Minification_%28programming%29
PHP is like a macro running on the server, it outputs text that is sent to the client. JS is scripting that the browser must interpret to update the contents of the page.
Question
If you use a single javascript file to hold all scripts, where do you put scripts that are for just one page?
Background
This may be a matter of opinion or "best practice" but I'm interested in others' opinions:
I'm using the html5 Boilerplate on a project. They recommend you place all javascript in a single file script.js for speed and consistency. Seems reasonable.
However, I have a bit of geolocation script that's only relevant to a single page, and not others. Should I break convention and just put this script on the page below my calls to the javascript libraries it depends on? Just put calls to the relevant functions (located in the script.js) file, below the links to the libraries they depend on?
Thanks!
The good folks at html5 boilerplate recommend putting all of your javascript in script.js so that the browser will only have to load that one file (along with the others that h5bp uses) and to allow caching of that file.
The idea is not to get caught up in the "recommended" way, and to think about things related to your own applications.
This geolocation file is only going to be used on this one page, right? It will never be used anywhere else.
The script.js file will be used on multiple pages.
Well, then it wouldn't make sense to put a "whole script" that will only be needed on one page in the script.js file. You should make the file external and call it separately on the page that it is needed. This will keep you from bloating the script.js file for functionality that may never get used by that user.
However, if your "whole script" for the geolocation functionality is pretty small, then include it in script.js. If it doesn't add to the speed of the download for that file, then it makes sense to include it there.
The gist of all of this is, What is the best trade off for my application?
These things we know to be true:
cached js files are good
fewer files to download are good
smaller files to download are good
maintenance is important
Once you think of these things in terms of your application, the decision making becomes a bit easier. And remember, decisions that trade off milliseconds are not going to make much of a difference in your user's "perception" of how fast your page is.
The browser will only download the .js files once (unless something is happening to discourage the browser from caching). So if you expect all of your users to hit the one page that uses geolocation sometime during their session, then you might as well give it to them early. If you expect maybe a tiny percent of your users to eventually hit the geolocation page, then maybe you might want to split them.
Split it out into a separate .js file so that it can be cached. Then reference both external .js files from your page.
I think you should put it in a separate file. Putting all the scripts in one single file could cause unexpected behavior and conflicts. I like to have one script file for the javascript that all pages will use containing plugins, helper functions, formatting functions etc. And then create one separate js file for everything that is relevant just for each page.
If you still want to have just one js file in the browser you could take advantage of one of those utilities that combine multiple js files into one.