Consider this pseudo code:
(function(window){
var options = { /*where everything goes */ };
var instance = (functio
What if is_allowed
would be completely local?
(function(window){
var options = {}, is_allowed;
var instance = (function(options){
for (var i in options) {
if (options.hasOwnProperty(i)) {
this[i] = options[i];
}
}
return this;
})(options);
instance.callbacks = function(cb){
/* ... */
};
function check_allowed(){
/* check and let this function set [is_allowed] */
};
window.instance = check_allowed()
? instance
: { callbacks: function(){(alert('not allowed'));} };
} (this) );
jsBin mockup
BTW: in your code, window.instance
would be undefined
.
If anyone ever wanted to manipulate this code (a malicious user for example), he would rewrite the is_allowed function with his own
He could rewrite your whole javascript code or not even use a browser but simulate a "browser-less" request to your server.
Is there ANY way that it work in old browsers (namely IE6-8) without too much hassle?
No. Anything you globally expose can be altered by the user, it is up to the browsers restrict the javascript:
behavior to avoid users from being fooled to access pre-crafted links. Firefox recently have made some kind of change to the javascript URL protocol.
As said on this article: http://survey-remover.com/blog/javascript-protocol-dangers/
As of Chrome v13, Firefox v6 and IE 9, the browser developers have taken notice to the dangers of the "javascript:" protocol and have subsequently disallowed code ... In the case of Chrome and IE, the "javascript:" substring is stripped when the code is pasted, whereas Firefox no longer executes the script within the scope of the active page.
So...
If it's impossible, then I'll just shrug and move on.
You should.
I won't say I'm an expert on these things. But assuming you can wrap your code completely and use events to trigger behavior you can use a structure like this:
Closed = function(args) { return (function() {
"use strict";
var secret, init, get_secret, use_secret;
init = function(something){
secret = something;
};
get_secret = function() {
return secret;
};
use_secret = function () {
console.log(secret);
};
/* Run constructor */
init(args);
/* Publish API */
return { use_secret:use_secret };
}())};
Setting it up with obj = Closed("Anything");
you can still have a malicious user overwrite the use_secret()
method, since it's exposed, but the get_secret()
method, and any other internals, are protected.
If your init method declares a number of event bindings to the application you can keep your state private in this way. The events will be able to trigger internal methods since they where bound from inside the inner closure but external code won't see them.
While this might solve your problem, I'm not 100% sure it does, it's not to be trusted anyway. Any user that want to penetrate your application can as long as the security is on the client side. There is nothing to stop them from crafting their own object to replace yours after the fact anyway, ES5 or no ES5.
For anything that actually needs to be secure you will have to revalidate on the server side. Never trust client side code to protect you, the request might not even come from the page you served ...