homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / Code, Content, and Presentation / JavaScript and AJAX
Forum Library, Charter, Moderator: open

JavaScript and AJAX Forum

This 72 message thread spans 3 pages: 72 ( [1] 2 3 > >     
Protect Javascript code
is that possible

 1:56 am on Nov 23, 2004 (gmt 0)


I was wondering if there is a way to protect a javascript code?
I took a long time to code some nice tools for my visitors but im afraid they will be copied easily without even asking for permission.

Not that i dont want to share, just that i d like to know about it kinda respect point of view :)




 2:29 am on Nov 23, 2004 (gmt 0)

The best you can do is obfuscate the code so that others will have a hard time modifying it. Of course, you keep a copy of the original.

As a bonus, obfuscated code should be smaller and therefore quicker to load.

I've never used such tools, but if you use the eval statement, I would test it is handled correctly.


Rambo Tribble

 1:59 pm on Nov 23, 2004 (gmt 0)

A recent thread featured a method of using PHP to generate an external .js script file. This appears to provide a good degree of protection.

Bernard Marx

 2:25 pm on Nov 23, 2004 (gmt 0)

In that thread [webmasterworld.com] I reckoned that the document could be saved as .mht in Internet Explorer. The .mht could be read to reveal the script.

I've just had a go with the PHP code provided. It does seem to work.
I saved as .mht, but the part that referred to the script was blank. So it does seem to bar all convenient methods of grabbing an external script.


 2:29 pm on Nov 23, 2004 (gmt 0)

If you use JavaScript on your site then I can copy it.
If I can copy it then a lot of people can - regardless of how you try to stop them.

Bernard Marx

 2:44 pm on Nov 23, 2004 (gmt 0)

Yes, but that technique appears to be easy, and makes copying just that little bit harder.
That's it. We know there ain't nothing we can do to stop the determined.
(none of my code's worth stealing, mind.)


 4:44 pm on Nov 23, 2004 (gmt 0)

Here's a thought.

Document your scripts, publish them and hope the links boost your PR.



 9:53 pm on Nov 23, 2004 (gmt 0)

I'm sorry I can't find the thread, but we discussed parsing .JS pages through the PHP engine to keep them from being cached ... with apparent success.


Add the .JS extension to your httpd.conf or .htaccess file:

AddType application/x-httpd-php .js

In EVERY .JS file, add the appropriate header info with PHP as the FIRST line:

header("Content-type: text/javascript");
... rest of scripts here ...

In your HTML pages, include the .JS file of choice:

<script type="text/javascript" src="somescripts.js"></script>

That's it. When the .JS file is parsed by PHP on request, it is not stored in the visitor's cache, AND visitors cannot see its contents when viewing the source.

Apparently. I haven't tried it, myself. :)


 12:14 am on Nov 24, 2004 (gmt 0)

As I said in that thread, view the html source to find the url of the javascript file, then type in that url. The browser will either prompt you to download the file or display it. The file is plain text no matter what you do - if it were otherwise the script would fail.

I don't care about the cache - unless I'm missing something it's simply not relevant.


Rambo Tribble

 3:00 am on Nov 24, 2004 (gmt 0)

Mr. Marx provided the link above. The point is, there is no .js file. The src value in the script tag is to a PHP script, which then outputs the JavaScript. The lines of JavaScript are in a .php file which can be in a protected directory, making direct access to the code difficult.


 11:45 am on Nov 24, 2004 (gmt 0)

Surely php simply delivers the js file - it still arrives as a text file. If I type the url (used as the script SRC attribute) either the browser will display the text file or it will offer to download it. Even if one or two browsers do neither, I'm sure I can find one that does.

As I understand it, browser behaviour depends on the content-type : this has been set to text/javascript. When I enter the url of a javscript file on my website IE offers to download it. Php or no php, I see no reason for IE to behave differently, but even if the content-type changes, I could still use an HTTP header checker that delivers raw page contents.

Is there a test site out there? I'll happily add a correction if I'm wrong.


Bernard Marx

 12:51 pm on Nov 24, 2004 (gmt 0)

I've stickied (stuck?) you the link to a 'live' version.
Purely a cut'n'paste job of the code provided (alert message n'all).

[quote]I could still use an HTTP header checker that delivers[/code]

Yes indeed. I think we're just looking for a hindrance to 'normal' or 'convenient' methods of retrieving the code. Nothing more. How those terms are defined is, of course, another matter. It does seem that you can't just cut'n'paste the src of the script tag, then download the script. That would put most off bothering.

Maybe further response header doings could 'discourage' the browser from cacheing the script file.

In my view, the balance of ease of implementation v. hindering effect is quite good (if you can be bothered in the first place that is). But the only 100% certainty involved is that it's not 100% safe - by any measure.

I wonder whether the the mime-type/content-type mix up would cause IE (with SP2) to refuse to use the script in a webpage.


 7:05 pm on Nov 24, 2004 (gmt 0)

This seems to be working well to:

1) Keep a .JS file from being downloaded separately
2) Keep a .JS file from being cached

(Building on the PHP header idea ... )

At the top of each .JS page:

<script type="text/javascript" src="somescript.js"></script>

if (!eregi("somepage",$_SERVER["REQUEST_URI"])) {
header("Location: http://www.google.com");
else {
header("Content-type: text/javascript");
... script contents ...

Of course, you would need to use an appropriate page name in each instance, or you could set up an array of all of the page names that use the .JS file and walk that array.

Anyway ... if the user requests the page normally, and the server is set up to parse .JS files with PHP, the page behaves normally, and the .JS file is not cached.


If the user tries to get the file by direct download, after seeing it's name in the source, then the "somepage" string is missing, and they're redirected to Google (or wherever).


Where else is left for the user to get the .JS file data? Not in the cache, not in the source, not by downloading it ... am I missing a method?


 7:11 pm on Nov 24, 2004 (gmt 0)

How about:

header("Location: http://www.mydomain.com/my_bad_robot_trap.php");

If you are using something like the PHP Bad Bot Script [webmasterworld.com] posted here at WW, snoopers get banned just like a bad bot... :D


 7:32 pm on Nov 24, 2004 (gmt 0)

Excellent! :)

And perhaps a more useful condition:


Obviates the need for individual page names, and still does the job.


 7:39 pm on Nov 24, 2004 (gmt 0)

Before people get carried away. The script (on the test page) only fires the first time I open the page. I then have to shut down the browser to make the script fire again.

Tested with IE and Firefox.

I'd call that a bug.



 7:59 pm on Nov 24, 2004 (gmt 0)

What do you mean, kaled?

Rambo Tribble

 8:41 pm on Nov 24, 2004 (gmt 0)

Kaled and I were sent a link to a page Mr. Marx had set up with the code, verbatim, from the first post in this thread: [webmasterworld.com...]

The alert only fires when the page is first loaded in a session (on Mozilla, at least). I imagine this may have to do with how the browser caches different types of files. This doesn't necessarily mean functions or variables would be unavailable; it simply suggests that the file is not re-read when the page reloads.

It is also possible that the manipulation of the expires header could modify the behaviour.


 9:01 pm on Nov 24, 2004 (gmt 0)

I imagine that the PHP attempt, above, would be subject to RAM-caching, as well. Even without caching to the hard disk, this could cause an attempt to download the .JS file after loading the page to be successful, if the browser pulls the RAM-cached copy instead of requesting the file from the server.

It's all so alpha! :)


 10:40 pm on Nov 24, 2004 (gmt 0)

One method I found that actually works rather well is to use a single frame that contains your site. You can then check for the existance of the parent frame and if it doesn't exist redirect them. If you also stop right click's then they can't view source. If they try to view source from the menu it shows them the frame source. If they try and access the page directly it redirects to an error page and when they view source it's just the error. Not that this does not work in opera since opera shows you the source of all loaded pages in all frames when you go through the main menu to view source. But it is one more way to stop people. I also implement most of the other methods discussed on this topic as well.


 11:24 pm on Nov 24, 2004 (gmt 0)

When I use an http checker on the script's url, the headers all seem ok, but only three further bytes of data appear <space><CR><LF>.

Now that does have me somewhat baffled. The following methods are all used to switch off caching.

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache



 11:05 am on Nov 25, 2004 (gmt 0)

there is no way to hide/protect JS which is disseminated via a web browser. you're all kidding yourselves.

Rambo Tribble

 3:18 pm on Nov 25, 2004 (gmt 0)

Actually, upon examination, I believe the foregoing is remarkably free of kidding, given the standards previously exhibited by the correspondents.

Bernard Marx

 3:28 pm on Nov 25, 2004 (gmt 0)

I'm sure most of us have witnessed or participated in enough "can you hide code?" threads in the past to be suffering from any delusions. "protect" can be a relative term, and this current angle is just being explored largely for the sake of it.

I do wish people would read threads before posting on them.

Rambo Tribble

 3:39 pm on Nov 25, 2004 (gmt 0)

Ultimately, the motivation behind hiding code must be examined. Two basic possibilities exist: either the writer believes his/her code so exceptional that it must be protected from theft, or the author doesn't wish to embarass him/herself by exposing hack code.

The former is outright delusional, the latter pathetically vain. Why would you want to hide your code?

Bernard Marx

 4:33 pm on Nov 25, 2004 (gmt 0)

Of course. There is an immediate irony involved when someone posts a request:
"How can I hide my script?".

Surely, if their script is all that, then they'd know...

On a different tack..

There are some sites (some even very good ones) that offer scripted systems for menus, and the like - all fully documented and supported. These scripts do get stolen, by which I mean used without licence. I know that Garrett Smith of DHTML kitchen has complained bitterly about this in the past. These scripts aren't 'hidden', and all the instructions are available. Not much can be done in this respect.

But how about scripts that aren't meant to be taken? What is the risk of one's oh-so-ingenious script being lifted off the web and used by someone else, for their own evil ends and gains? Is it fair to say that the more "stealworthy" a script is, the harder it is to port to another page without instruction? (perhaps not).

Does it actually happen much?


 4:54 pm on Nov 25, 2004 (gmt 0)

Anything that is exported to the client side can be stolen.

So anything you write that runs on the client side is at risk.

That's a simple fact of web life.

Now look at all the insanely successful websites: Goggle, eBay, Amazon....

Even if you steal their JS and their HTML you've got maybe 1/100th of a percent of anything of value about their site.

Their depth, their value, their success comes from focusing on the server side processes.

Server side intelligence can be hidden. Usually is. And is the way to wealth.

Discussions about hiding client side stuff is a distraction from making the best of the web.

Bernard Marx

 5:31 pm on Nov 25, 2004 (gmt 0)

Just a little distraction is what I was after.


 10:38 pm on Nov 25, 2004 (gmt 0)

I've enjoyed this thread and not because I am deluded into thinking my scripts have value to others. :D

I'd say the prevailing reason I enjoy coding is for the challenge of tackling something new to me. Any new ideas on protecting code are worth exploring for the same reason -- a problem to solve.

Recognizing the patched together nature of the code I write, I realize that for someone to take it and use it, they would need to be smart enough to reverse engineer my junk to modify for their purposes but not smart enough to write it themselves.

I know that a determined car thief will take a crowbar to my window yet I still lock my doors. Why wouldn't I "lock the doors" on my website? ;)


 11:30 pm on Nov 25, 2004 (gmt 0)

Rambo: however hard you try, however well you code the PHP/ASP/JSP/CFML, etc, I can still get the JS:

file/save as ... and i have everything. no matter how hard you code, the code will still be available. hence, for Js, there's no point in trying to stop its download.

This 72 message thread spans 3 pages: 72 ( [1] 2 3 > >
Global Options:
 top home search open messages active posts  

Home / Forums Index / Code, Content, and Presentation / JavaScript and AJAX
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved