I hope the question didn't confuse you firstly. I'm very picky on security and do not want to have ANY PHP files anywhere in the public_html folder, but on the private area usually before this directory "../public_html". Here's a quick example of my needs, and do believe .htaccess will rescue me (or one of you guys!) with a solution. Inside JS I get data I want to send to PHP. I'm not going to write all the JS code but you'll understand surely. The JS file is located here: c://wamp64/public_html/assets/js/send_ajax.js and index /public_html/index.php
var username = helloWorlder;
/* and all the onreadystate change content here */
xmlhttp.open("POST", "this_is_the_problem_file_name.php", true);
xmlhttp.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
xmlhttp.send("u=" + username);
You see the file I'm POSTing to, I want to have a rewrite condition so it can point to this example C://wamp64/private_area/php/this_file.php. I don't want to do this in the JS script ../../../private_area/this_file.php because that will be TOO much revealing a sensitive directory. To clarify the index page, and of course JS file is public. The PHP file isn't. Surely there's a way. Thanks in advance.
.htaccess and javascript will only be able to communicate with what is publicly accessible by the browser. What you will probably want is an intermediary controller. You can set up a snippet in MODX that loads your hidden PHP files, set up a blank page that calls that snippet, then post your requests to that page and read the responses.
You can't make a request that gets processed by a PHP program unless you give that PHP program a URL.
The easiest way to do that is to put the PHP program under the server root.
You could use alias or mod_rewrite to keep the file elsewhere, but that is largely pointless.
The only benefit that gives you is that in the unlikely event of something going wrong with your server configuration which might leak the source code of the PHP program, then it will likely go sufficiently wrong to break access to it entirely.
You can get the same benefits, without the complexity, by putting the sensitive parts of the program outside the server root and then include()ing them.
I have tried every possible question here on stackoverflow but unable to resolve this issue ...
<!--#include virtual="include.shtml"-->
<!--#include virtual="include.html"-->
<!--#include file="include.shtml"-->
<!--#include file="include.html"-->
<!--#include virtual="/include.shtml"-->
<!--#include virtual="/include.html"-->
<!--#include file="/include.shtml"-->
<!--#include file="/include.html"-->
<? include("/include.shtml"); ?>
<? include("include.shtml"); ?>
<? include("/include.html"); ?>
<? include("include.html"); ?>
I tried with apache server running at localhost/include/index.html or file:///home/sahil/Desktop/include/index.html with all above includes but none of them is working for me :( .Now which method should i use to include one HTML file into another , considering my index.html and include.html both are in same directory ???
The former syntax is SSI, the latter is PHP. Both are server technologies and will only work if accessed from an HTTP server that supports and is configured to check the file for the syntax (which usually means you have to turn the support on and use a .shtml/.php file extension (or change the config from the default to determining which files to check)). Other server side technologies are available.
The only "include" mechanisms in HTML itself are (i)frames and objects.
You could also consider a template system such as TT that you could run as a build step to generate static HTML documents (NB: TT can also be used on the fly).
HTML is Static
It is not possible to include a HTML page within another HTML page with static HTML because it is simply not supported by HTML. To make your HTML dynamic, you have 2 possibilities: use a client side script or use a server side technology.
...Unless you start using frames (dropped with the HTML5 standard) or iframes that are most likely not a solution because of the fact that it is treated as a completely different web page.
Client Solution
You could create a JavaScript file and write your HTML with the document.write function and then include the JavaScript file where ever you need it. Also, you could use some AJAX for this, but there are JavaScript libraries out there that could ease your burden such as the popular jQuery library.
Yet, I would not suggest using a client solution because it is more trouble than it is worth...
Server Solution
There are many server side solutions out there: ASP, ASP.NET, ASP.NET MVC, Java, PHP, Ruby and the list goes on. What you need to understand is that a server a side technology could be described as a parser for a specific server side language to automate certain tedious tasks and to perform actions that would represent a security risk on the client.
Of course you will need to have the means to host such a site and to configure the hosting environment. For example, you could host a PHP website with Apache and even have a developer hosting environment such as /MAMP/LAMP/WAMP.
You can view an example of including a page in PHP in the online documentation.
Personally, I would be more inclined to use a server side solution.
HTML doesn't have an 'include' mechanism - I'm not sure where you've seen these solutions on StackOverflow. You've probably been looking at answers for a server side language such as PHP or ASP.
You do have the following options for 'pure' HTML where you only have static pages and JavaScript:
Frames
Ajax
See my answer here for sample code and more details (and also a caveat about SEO if that matters to you).
Make your html file you want to include to php file. (only change the extension - to .php). If the files are in one directory, include code is:
<?php include "nameoffile.php" ?>
Sometimes when I need to include the same group of elements in many web pages, I use PHP:
<?php include "somefile.html" ?>
When somefile.html is this:
<h1>TITLE</h1>
<h2>Subtitle</h2>
And sometimes, when I'm too lazy to use PHP and turn on my local server, I use JS:
<script src="somescript.js"></script>
When somescript.js is like this:
document.write(
"<h1>TITLE</h1>" +
"<h2>Subtitle</h2>"
);
The second version is just a tiny bit more inconvenient, but I use both ways.
However, I was wondering which way is customary and which way is faster.
I know PHP is server-side and is pre-parsed into HTML first, but even though it loads before the JS does, I don't know if it's faster. Because JS is client-side, it is parsed by the browser and might be quicker than sending a request to the server (although I'm not totally sure - tell me if I'm making incorrect inferences).
Feel free to tell me if I'm unclear and redirect me to another page that could help.
Thanks.
The second way is not only worse performance wise, it's an awful practice that could potentially erase your entire page because of how document.write() works. You shouldn't be using document.write() unless you are VERY sure you need to, which is rare. The only case I know of in which it is acceptable is for fallbacks of cdn delivered javascript. You use it to write in script tags for a local copy, like this:
<script src="http://code.jquery.com/jquery-latest.js"></script>
<script>window.jQuery || document.write('<script src="sys/lib/jquery.js"><\/script>')</script>
Consider that the script you're including is on the server, so a request has to be sent for it and it must be loaded before the page can continue or finish loading. The server could have just sent that data to begin with.
The first is definitely more customary, more efficient, and faster.
These are the actions I can point out to simply count the network and i/o interactions from a very high level.
php include:
User requests
apache processes
php processes from disc
apache sends data for display
js include:
user requests
apache processes
(assuming html extension is not processed by php)
apache sends data for display
js tells browser to include another file
apache processes request for another file
apache sends data for inclusion
js process displays data
The first method is slower for the server, and the second is slower for the client. Though, in practice, both methods should be fast enough for normal use cases. I would recommend the first method though.
I know it's impossible to hide source code but, for example, if I have to link a JavaScript file from my CDN to a web page and I don't want the people to know the location and/or content of this script, is this possible?
For example, to link a script from a website, we use:
<script type="text/javascript" src="http://somedomain.example/scriptxyz.js">
</script>
Now, is possible to hide from the user where the script comes from, or hide the script content and still use it on a web page?
For example, by saving it in my private CDN that needs password to access files, would that work? If not, what would work to get what I want?
Good question with a simple answer: you can't!
JavaScript is a client-side programming language, therefore it works on the client's machine, so you can't actually hide anything from the client.
Obfuscating your code is a good solution, but it's not enough, because, although it is hard, someone could decipher your code and "steal" your script.
There are a few ways of making your code hard to be stolen, but as I said nothing is bullet-proof.
Off the top of my head, one idea is to restrict access to your external js files from outside the page you embed your code in. In that case, if you have
<script type="text/javascript" src="myJs.js"></script>
and someone tries to access the myJs.js file in browser, he shouldn't be granted any access to the script source.
For example, if your page is written in PHP, you can include the script via the include function and let the script decide if it's safe" to return it's source.
In this example, you'll need the external "js" (written in PHP) file myJs.php:
<?php
$URL = $_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'];
if ($URL != "my-domain.example/my-page.php")
die("/\*sry, no acces rights\*/");
?>
// your obfuscated script goes here
that would be included in your main page my-page.php:
<script type="text/javascript">
<?php include "myJs.php"; ?>;
</script>
This way, only the browser could see the js file contents.
Another interesting idea is that at the end of your script, you delete the contents of your dom script element, so that after the browser evaluates your code, the code disappears:
<script id="erasable" type="text/javascript">
//your code goes here
document.getElementById('erasable').innerHTML = "";
</script>
These are all just simple hacks that cannot, and I can't stress this enough: cannot, fully protect your js code, but they can sure piss off someone who is trying to "steal" your code.
Update:
I recently came across a very interesting article written by Patrick Weid on how to hide your js code, and he reveals a different approach: you can encode your source code into an image! Sure, that's not bullet proof either, but it's another fence that you could build around your code.
The idea behind this approach is that most browsers can use the canvas element to do pixel manipulation on images. And since the canvas pixel is represented by 4 values (rgba), each pixel can have a value in the range of 0-255. That means that you can store a character (actual it's ascii code) in every pixel. The rest of the encoding/decoding is trivial.
The only thing you can do is obfuscate your code to make it more difficult to read. No matter what you do, if you want the javascript to execute in their browser they'll have to have the code.
Just off the top of my head, you could do something like this (if you can create server-side scripts, which it sounds like you can):
Instead of loading the script like normal, send an AJAX request to a PHP page (it could be anything; I just use it myself). Have the PHP locate the file (maybe on a non-public part of the server), open it with file_get_contents, and return (read: echo) the contents as a string.
When this string returns to the JavaScript, have it create a new script tag, populate its innerHTML with the code you just received, and attach the tag to the page. (You might have trouble with this; innerHTML may not be what you need, but you can experiment.)
If you do this a lot, you might even want to set up a PHP page that accepts a GET variable with the script's name, so that you can dynamically grab different scripts using the same PHP. (Maybe you could use POST instead, to make it just a little harder for other people to see what you're doing. I don't know.)
EDIT: I thought you were only trying to hide the location of the script. This obviously wouldn't help much if you're trying to hide the script itself.
Google Closure Compiler, YUI compressor, Minify, /Packer/... etc, are options for compressing/obfuscating your JS codes. But none of them can help you from hiding your code from the users.
Anyone with decent knowledge can easily decode/de-obfuscate your code using tools like JS Beautifier. You name it.
So the answer is, you can always make your code harder to read/decode, but for sure there is no way to hide.
Forget it, this is not doable.
No matter what you try it will not work. All a user needs to do to discover your code and it's location is to look in the net tab in firebug or use fiddler to see what requests are being made.
From my knowledge, this is not possible.
Your browser has to have access to JS files to be able to execute them. If the browser has access, then browser's user also has access.
If you password protect your JS files, then the browser won't be able to access them, defeating the purpose of having JS in the first place.
I think the only way is to put required data on the server and allow only logged-in user to access the data as required (you can also make some calculations server side). This wont protect your javascript code but make it unoperatable without the server side code
I agree with everyone else here: With JS on the client, the cat is out of the bag and there is nothing completely foolproof that can be done.
Having said that; in some cases I do this to put some hurdles in the way of those who want to take a look at the code. This is how the algorithm works (roughly)
The server creates 3 hashed and salted values. One for the current timestamp, and the other two for each of the next 2 seconds. These values are sent over to the client via Ajax to the client as a comma delimited string; from my PHP module. In some cases, I think you can hard-bake these values into a script section of HTML when the page is formed, and delete that script tag once the use of the hashes is over The server is CORS protected and does all the usual SERVER_NAME etc check (which is not much of a protection but at least provides some modicum of resistance to script kiddies).
Also it would be nice, if the the server checks if there was indeed an authenticated user's client doing this
The client then sends the same 3 hashed values back to the server thru an ajax call to fetch the actual JS that I need. The server checks the hashes against the current time stamp there... The three values ensure that the data is being sent within the 3 second window to account for latency between the browser and the server
The server needs to be convinced that one of the hashes is
matched correctly; and if so it would send over the crucial JS back
to the client. This is a simple, crude "One time use Password"
without the need for any database at the back end.
This means, that any hacker has only the 3 second window period since the generation of the first set of hashes to get to the actual JS code.
The entire client code can be inside an IIFE function so some of the variables inside the client are even more harder to read from the Inspector console
This is not any deep solution: A determined hacker can register, get an account and then ask the server to generate the first three hashes; by doing tricks to go around Ajax and CORS; and then make the client perform the second call to get to the actual code -- but it is a reasonable amount of work.
Moreover, if the Salt used by the server is based on the login credentials; the server may be able to detect who is that user who tried to retreive the sensitive JS (The server needs to do some more additional work regarding the behaviour of the user AFTER the sensitive JS was retreived, and block the person if the person, say for example, did not do some other activity which was expected)
An old, crude version of this was done for a hackathon here: http://planwithin.com/demo/tadr.html That wil not work in case the server detects too much latency, and it goes beyond the 3 second window period
As I said in the comment I left on gion_13 answer before (please read), you really can't. Not with javascript.
If you don't want the code to be available client-side (= stealable without great efforts),
my suggestion would be to make use of PHP (ASP,Python,Perl,Ruby,JSP + Java-Servlets) that is processed server-side and only the results of the computation/code execution are served to the user. Or, if you prefer, even Flash or a Java-Applet that let client-side computation/code execution but are compiled and thus harder to reverse-engine (not impossible thus).
Just my 2 cents.
You can also set up a mime type for application/JavaScript to run as PHP, .NET, Java, or whatever language you're using. I've done this for dynamic CSS files in the past.
I know that this is the wrong time to be answering this question but i just thought of something
i know it might be stressful but atleast it might still work
Now the trick is to create a lot of server side encoding scripts, they have to be decodable(for example a script that replaces all vowels with numbers and add the letter 'a' to every consonant so that the word 'bat' becomes ba1ta) then create a script that will randomize between the encoding scripts and create a cookie with the name of the encoding script being used (quick tip: try not to use the actual name of the encoding script for the cookie for example if our cookie is name 'encoding_script_being_used' and the randomizing script chooses an encoding script named MD10 try not to use MD10 as the value of the cookie but 'encoding_script4567656' just to prevent guessing) then after the cookie has been created another script will check for the cookie named 'encoding_script_being_used' and get the value, then it will determine what encoding script is being used.
Now the reason for randomizing between the encoding scripts was that the server side language will randomize which script to use to decode your javascript.js and then create a session or cookie to know which encoding scripts was used
then the server side language will also encode your javascript .js and put it as a cookie
so now let me summarize with an example
PHP randomizes between a list of encoding scripts and encrypts javascript.js then it create a cookie telling the client side language which encoding script was used then client side language decodes the javascript.js cookie(which is obviously encoded)
so people can't steal your code
but i would not advise this because
it is a long process
It is too stressful
use nwjs i think helpful it can compile to bin then you can use it to make win,mac and linux application
This method partially works if you do not want to expose the most sensible part of your algorithm.
Create WebAssembly modules (.wasm), import them, and expose only your JS, etc... workflow. In this way the algorithm is protected since it is extremely difficult to revert assembly code into a more human readable format.
After having produced the wasm module and imported correclty, you can use your code as you normallt do:
<body id="wasm-example">
<script type="module">
import init from "./pkg/glue_code.js";
init().then(() => {
console.log("WASM Loaded");
});
</script>
</body>
For example, having:
<script type="text/javascript"
src="http://somedomain.com/js/somejs.js?14">
</script>
So what does "?14" means here?
Its a url param like any other parameter passed in a url. Sometimes JS scripts are created on the fly using server side technologies other times it is simply a version number to help with browser caching issues.
They are there to fool browsers into thinking that it is a new file.
This is a trick to avoid browser-cached copy when you update the JS file.
It means a variable is being passed to the script via GET, though standard JavaScript files don't support any means of collecting the variable.
You could, however, write a server script in PHP or ASP.NET that sets the content type as application/x-javascript.
Like this in php:
// file: external.php
<?php header("content-type: application/x-javascript"); ?>
// regular javascript here that uses $_GET['variable'];
Then you could put this in your HTML script tag:
<script type="text/javascript" src="external.php?variable=14"></script>
The javascript script is probably generated by a server side script (PHP, CGI, etc.) , which takes 14 as a parameter.
This is a query parameter as the browser will make an http get request to the somedomain.com for the javascript source.
If you load the page with a header browser like fiddler, you will see exactly what's going on.
IMHO, a JavaScript source like this will request "dynamic" content from server, thus the server will not try to use cached version of JavaScript file. Whether or not the parameter really does matter is up to the server.