Hide Javascript when building a widget

I am creating a web widget that will be very easy to integrate. Let's say http://www.bicycleseller.com/ wants to integrate my widget into its web page. All he needs to do is copy and paste the following into the chapter section of his page:

 <script src="http://www.widgetprovider.com/widget.js" type="text/javascript"></script> <script> Widget.create("123456accessKeyOfBicycleSeller").render("myWidget"); </script> 

and <div id="myWidget"></div> anywhere in the body. The widget will be displayed in this div.

I, as a widget provider, host widget.js :

 var Widget = new function () { this.url = "www.widgetprovider.com/widget.jsp"; this.name = ""; this.parameters = "width=400,height=200,screenX=750,screenY=300,resizable=0"; this.create = function (accessKey) { this.accessKey = accessKey; return this; }; this.render = function (divId) { // make sure the document is fully loaded and place the widget on BicycleSellers page. // when the widget (a jpeg) is clicked, a jsp page I host will popup. window.onload = function () { document.getElementById(divId).innerHTML = '<img src="images/widget-image.jpg" onclick="Widget.display()"/>'; }; return this; }; this.display = function () { // open a popup window that displays a page I host. var popup = window.open(this.url + "?accessKey=" + this.accessKey, this.name, this.parameters); popup.focus(); return this; }; }; 

So, BicycleSeller places the widget on its page, and when its users click on it, a pop-up window appears that displays their contents on the page that I place. However, every webmaster who wants to embed my widget must provide an accessKey that is unique to them, because the contents of the popup will depend on this.

My questions:

1) . In this case, anyone who goes to bicycleseller.com and looks at the HTML source code can see its accessKey , which is hardcoded in the section of the chapter. Then they can simply go to www.widgetprovider.com/widget.jsp?accessKey=123456 . I do not want this to happen. What can be done about this? For instance; I looked at the source of Facebook, and they seem to have hidden everything very well.

2) Is this a good way to create a widget? I was thinking about a lightbox, not a popup (which might be blocked by a popup blocker, although this is not the case in this example). Any comments / suggestions are welcome.

3) If I try to place in widgets and write Widget.create("key1").render("div1"); Widget.create("key2").render("div2"); Widget.create("key1").render("div1"); Widget.create("key2").render("div2"); , two images will be created. But when clicked, both pop-ups display key1 information. This is because the Widget class in widget.js is single. If I do not make it single, then I cannot put the image onclick attribute ( Widget.display() ). What should I do for this?

Seek help on three issues. Any help would be appreciated. Thanks.

+4
source share
4 answers

Your server can check the "Referer" header of the request. This will force random users to view the contents of the pop-up context out of context by entering a URL in the address bar or using a third-party link. Headers can be faked, but it takes some effort and is not a standard browser feature.

You will not be able to stop a hacker from loading a pop-up from context on his own computer.

As for pop-ups, which is a good idea, I think something built-in would be better, but work more and less portable, so you need to decide if there are enough pop-ups.

To make a widget not single, but not:

 $(window).load(function () { document.getElementById(divId).innerHTML = '<img src="images/widget-image.jpg" onclick="Widget.display()"/>'; }); 

using:

 var widget = this; $(window).load(function () { var image = document.createElement("img"); image.src="images/widget-image.jpg"; image.onclick = function() { widget.display() }; document.getElementById(divId).appendChild(image); }); 

By setting onclick to the actual function instead of the code for the function, you can return to the Widget instance through closure.

+1
source

I think you should point out that your javascript based widget can be cached and (even if it is not cached), the client can view the source. After all, javascript is executed on the client computer, not on your server.

To “hide” things like the one you want to do, you need to make sure that the “sensitive data” is processed by server-side scripts. Everything that a client can download can be viewed and used by clients. The only thing they can’t get on is what happens on the screens “behind the screens” on your server. Therefore, if you want to hide something, keep it on your server.

The only level of security you can get with javascript is obfuscation. But this is a level of security that can be lifted by almost everyone who invests a little time. (Read: script kids will love reversing things like this for fun!)

+1
source

For your first question, I think @JGWeissman gave a possible solution.

In response to your second question, I do not think that a user-initiated click to open a pop-up will be stopped by a pop-up blocker. I believe that blockers are looking for code that runs regardless of what the user does on the page. It's quite simple to make your own lightbox like a popup, but it may not be worth the time, especially since you do not control the page you are embedded on. They may have built-in Flash, which may not match pop-up solutions like lightbox, which can cause headaches.

In response to the third question, I will make it so that every time you “create” a widget, you actually create an object that represents it. You can track widget "instances" in your Widget object in an array. You can also create an instance of the window.onload method, which loops through the "instances" and provides each click method that will launch accessKey instances. I would also get rid of the separation between creation and rendering, as you seem to name them together. So here is one way to do this:

 var Widget = new function () { var widgets = []; this.url = "http://www.yahoo.com"; this.name = ""; this.parameters = "width=400,height=200,screenX=750,screenY=300,resizable=0"; window.onload = function () { var w; for (w = 0; w < widgets.length; w++) { document.getElementById(widgets[w].id).innerHTML = '<img src="images/widget-image.jpg" onclick="Widget.display(' + w + ')"/>'; } }; this.display = function (index) { widgets[index].display();//display the widget instance corresponding to the index } this.create = function (accessKey, elId) { var newWidget = { accessKey: accessKey, id: elId, display: function () { // open a popup window that displays a page I host. var popup = window.open(Widget.url + "?accessKey=" + accessKey, Widget.name, Widget.parameters); popup.focus(); } }; widgets.push(newWidget); return newWidget; }; }; 
0
source

I do not know about 2 and 3, but I can answer 1.

What you can not : prevent people from looking at your source code. Everything can be faked, you can stop random users, but you will not stop a specific person for more than a few seconds (yes, seconds). What you can do is prevent users from using your code on their site.

You can create links that are not valid after a period of benefits that you control. Example:

 $key = "client_key"; $time = $_SERVER['REQUEST_TIME']; $hash = md5("nonce" . $key . $time); // super secret method than no one should ever find out return return "hash=" . $hash . "&key=" . $key . "&time=" . $time; 

This requires that you post server code on your client’s website. The hash ensures that no one can "mess up" the variables, because no one knows the method you use for hashing (choose something a little more obscure, add the correct nonce value). The time variable, which you can use to reject requests with a very old time value, for example: 24 hours.

However, you cannot prevent people from retrieving the code once and keep a local copy for themselves, but at least you excluded them from updates and bug fixes.

You can also add obfuscation so that they cannot easily modify or maintain code.

It is simply impossible to completely prevent people from “stealing” your JavaScript.

0
source

Source: https://habr.com/ru/post/1384985/


All Articles