保护专有 HTML/CSS/JavaScript 的最佳方法是什么?
我正在使用 HTMl、CSS 和 JavaScript 编写一个健壮、可扩展且相当复杂的网站引擎。我不希望它被盗用,我想知道是否有任何方法可以保护源代码不被客户端查看。
我特别关心 JavaScript,我想知道是否可以通过将其托管在无法直接查看的单独文件中来保护它。我可以完全控制我的网络服务器,并且可以更改任何设置以适应。
I am writing a robust, scalable, and fairly complex website engine using HTMl, CSS, and JavaScript. I don't want it to get ripped off, and I'm wondering if there's any way to protect the source from being viewed in the client.
I am particularly concerned about the JavaScript, and I'm wondering if I can protect it by hosting it in seperate files that cannot be viewed directly. I have full control of my web server, and I can alter any settings to accomodate.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(10)
做完全相反的事情,使用 MIT/GPL 许可证将您的代码作为开源发布。将您的(公司)名称附加到代码中,并被称为第一个创建应用程序 X 的人。声誉会让您比“保护您的代码”的徒劳尝试走得更远。
对于 JS/CSS/HTML 而言,确实没有合理的理由保护您的代码,您能做的最好的事情就是通过将其保留在后端来保护您的业务逻辑。
最好的例子,我可以编写自己的 CKEditor 实现(很多人都这样做),但是仅使用 CKEditor 就容易得多,而且每个人都知道它是什么,谁写的等等。
或者以谷歌地图为例,周围有很多克隆地图,但真正的谷歌地图只有一个。哎呀,其他人在谷歌之前就已经编写了地图实现,但谷歌地图更出名。
我可以继续举出很多例子,为什么试图保护你的代码不仅愚蠢,而且实际上并不聪明......保护业务逻辑是一回事,但实际上通过公开你可以获得更多收益带有花哨的 sancy 前端代码...
Do the exact opposite, release your code as opensource with an MIT/GPL license. Attach your (business) name to the code and be known as the first to create application X. Reputation gets you much farther then futile attempts to "protecting your code".
There's really no sane reason to protect your code where JS/CSS/HTML is concerned, the best you can do is protect your business logic by keeping that on the backend.
Prime example, I could write my own implementation of CKEditor (a lot of people do just that) but it's a heck of a lot easier to just use CKEditor and everyone knows what it is, who wrote it etc.
Or take google maps as example, there are a lot of clones around, but there's only one real google maps. Heck, others had written a maps implementation before google, but google maps is more reknowned.
I could go on with lots of examples why trying to protect your code is not only silly, but actually not smart... Protecting business logic is one thing, but you actually have more to gain by going public with fancy smancy frontend code...
不管你如何混淆代码,任何人只要看到它就可以复制你正在做的事情。从头开始编写它可能需要更长的时间,但对此您无能为力。
您唯一真正的保护选择包括对代码进行版权保护,并可能申请专利。如果您所做的事情确实与众不同,那么专利可能是最好的选择。
通常,您的应用程序的价值实际上在于支持领域。换句话说,如果人们觉得你会存在足够长的时间来支持它,他们就会购买它。定价时请注意这一点。
您会发现有些人会简单地窃取您的代码并重用它。不要太担心他们,因为无论如何他们都不会付费。相反,让您自己的客户轻松购买和使用您的产品。确保您提供支持;这才是真正价值的来源。
Regardless of how you obfuscate the code, anyone can replicate what you are doing just by seeing it. It might take a little longer to write it from scratch, but there's not much you can do about that.
Your only true options for protection involve copyrighting the code and, potentially, filing a patent. If what you are doing is truly different, then a patent is probably the best way to go.
Typically the value in your application is really going to be in the support area. In other words, people will buy it if they feel that you will be around long enough to support it. Be aware of this as you price it.
You're going to find that there will be some that will simply steal your code and reuse it. Don't worry too much about them as they weren't going to be paying customers anyway. Instead, make it easy for your own customers to buy and use your stuff. Make sure you provide support; that's where the real value is going to come from.
不,你不能那样做。
一切都将交给浏览器(客户端)。你可以用它来混淆 uglify、minify 或诸如此类的东西,但最后很容易再次“加密”它。
您也无法隐藏它,因为您希望浏览器接收所有来源。因此,即使您做了一些时髦的举动,例如“通过动态脚本标签插入加载 javascript,然后删除脚本标签”。好吧,这可能对一些没有经验的用户有用,但使用像 Fiddler 这样的工具将再次显示真相。
No you cannot do that.
Everything is going to the browser (the client). You may obfuscate uglify, minify or whatnot with it, but at the end it's an easy shot to "encrypt" that again.
You can't hide it either, because you want the browser to receive of all you sources. So even if you do some funky move like, "loading javascript with dynamic script tag insertion and remove the script tags afterwards". Well that might work for some unexperienced users, but using a tool like
Fiddler
will show the truth again.你根本不能那样做。使用最小化器混淆你的 javascript 和 CSS 可能是你能得到的最接近的结果。
You simply can't do that. Obfuscating your javascript and CSS with a minimizer is probably the closest you can get.
好吧,普遍的答案是“不要把它放在网上”。然而,你可以对你的 JavaScript 进行如此大的混淆,以至于通常没有人会费心去窃取它。删除函数和变量名称等有很大帮助。一般来说,从头开始会更容易。
Well, the popular answer is going to be "don't put it on the web". However, you can obfuscate your javascript so much that, typically, no one will bother stealing it. Removing function and variable names and the like goes a long way. Generally it will be easier to start from scratch.
缩小 HTML、CSS 和 JavaScript 会有一点帮助,但人们总是可以重新格式化它们。最好的办法是发送给客户的内容与您正在使用的原始内容不同。
这可以通过以下方式实现:
但是,对于所有这些,您能做到的就只有这么多了。编译你的 JavaScript 会让你更难遵循你的初衷,但如果有人决心对其进行逆向工程,那么可能还不够困难。
Minifying your HTML, CSS, and JavaScript will help a small bit, but people can always reformat those. Your best bet is if the contents sent down to the clients aren't the same as the original contents that you're working with.
That can be achieved by:
However, with all of those, there's only so far that you can go. Compiling your JavaScript will make it harder to follow your original intentions, but probably not difficult enough if someone sets their mind to reverse-engineering it.
您可以不将其放在互联网上,也可以仅通过内部网进行访问;但是没有办法可靠地阻止客户端访问 html/css/JS,而不阻止他们访问网站本身。
混淆将阻止随意尝试和好奇浏览,但不会阻止坚定的攻击者/浏览器,因为它都是在客户端实现的。
You can either not put it on the internet, or keep it accessible only via an intranet; but there's no way to reliably prevent the client from accessing the html/css/JS, without preventing them from accessing the site itself.
Obfuscation will deter casual attempts, and curiosity-browsing, but won't prevent a determined attacker/browser since it's all implemented on the client-side.
您可以使用 JavaScript 混淆器。这将使代码难以阅读。他们仍然可以“抄袭”,但很难理解它并因此修改它。您无法完全隐藏代码。
You can use a JavaScript obfuscator. It will make the code difficult to read. They can still "rip it off", but it would be very difficult to understand it and therefore modify it. There is no way you can hide the code completely.
我对这个问题思考了很多,但坦率地说,我无能为力。我遇到过的最好的方法是使用 JS 编译器。
从理论上讲,我从未真正这样做过,但我确实知道这是可能的,可以通过 1x1 像素的 swf 加载您的 js,而该 swf 又通过加扰器发送。仍然可以解决这个问题,但它变得更更烦人。然后,您可以将 aes 加密代码发送到 swf,在客户端对其进行解密(使用 as3crypt 库),然后将其写入浏览器。也就是说,除非您使用 swf 进行一系列回调,否则您仍然会遇到这样的问题:它仍然需要写入浏览器。 Firebug 和其他浏览器的 js 控制台将让用户获取“已编译”的 js。当然,可以编写 AS3 脚本来注册一系列回调...
正如我所说,这更多的是假设性的,虽然我毫不怀疑它可以在田园诗般的情况下工作,但 Flash 是有限的,你需要 AS3 的知识。当然,这样做的好处是,这是一种将 js 获取到浏览器而用户却无法轻松阅读的方法。
I've thought about this problem a lot and, frankly, there isn't much which can be done. The best I've ever come across is using a JS compiler.
Theoretically, and I've never actually done this but I do know that it is possible, it might be possible to load your js through a 1x1 pixel swf which was in turn sent through a scrambler. It is still possible to get around that, but it becomes far more annoying. Then, you would be able to send aes encrypted code through to the swf, decrypt it client side (using as3crypt libraries), and then write it to the browser. That said, unless you were using the swf for a series of callbacks, you'd still have the problem of the fact that it would still need to be written to the browser. Firebug and the other browsers' js consoles would let the user get the "compiled" js. Of course, it is possible to script AS3 to register the series of callbacks...
As I've said, this is more hypothetical than not and while I've no doubt that it could work in idyllic situations, Flash is limited and you'd need knowledge of AS3. The benefit, of course, is that this is a way to get js to the browser without the user being able to read it easily.
我真的不相信可以向最终用户隐藏 JavaScript 代码,JavaScript 是在客户端而不是服务器端完成的,这意味着以纯文本形式查看源代码或让第三方程序拦截浏览器、最终用户越好,需要代码来完成任务。
即使它是加密的,在某个时间点,浏览器也必须对其进行未加密才能完成并显示任务,最终用户将在其中获取代码,除非您对最终用户的信息有完全的控制权。计算机隐藏客户端执行的任何代码是不可能的。
I don't really believe it's possible to hide JavaScript code from the end user, JavaScript is done client side not server side meaning the better it is viewing the source code in plain text or having a third party program intercept the browser, end user, requires the code to complete the task.
Even if it's encrypted, at some point in time it is going to have to be un-encrypted for the browser to complete and show the task, where the end user will obtain the code, unless you have complete and total control over the end user's computer hiding any code which is executed client side would be impossible.