 |
|
|
 首页 |
名片设计 CorelDRAW Illustrator AuotoCAD Painter 其他软件 Photoshop Fireworks Flash |
|
DHTML使得我们能够开发出功能强盛的Web应用客户端，它具有跨浏览器兼容、可交互和可移植等特点。它的缺点是用户能够直接查看JavaScript代码。本文介绍如何运用ASP技术保护DHTML代码，防止有人窃取你的DHTML代码。 传统保护技术众所周知，Web本质上是一种不安全的媒介。当用户访问Web应用或者打开Web页面时，所有客户端的代码（HTML， JavaScript源文件以及CSS样式）一般都要下载到客户端缓冲区。用户只需点击一下“查看源文件”就可以查看、分析和复制这些代码。 MSDN摘录了Wrox《Instant JavaScript》一书的部分内容，它指出了保护JavaScript代码的几种方式，详细请参见这里。 客户端JavaScript代码保护方式主要可以分成如下几类： a）Microsoft的方式：Microsoft通过发布Windows Script Engine Version 5.0来解决客户端源代码保护问题。源代码通过一个ActiveX层编码（不是加密）。请参见Script Encoding with the Microsoft Script Engine Version 5.0。 这种方式的缺点是经过编码的代码只有IE 5.0+才能解码，而且他们坦率承认编码过程并非简朴易行。假如你使用的是其他浏览器（包括IE浏览器的早期版本），你就不能通过浏览器访问脚本代码。 b）模糊代码（Code Obfuscation）：一些共享软件，比如Jammer以及JMyth，企图通过让代码变得难于阅读、让变量名字变得杂乱去防止有人偷窃 JavaScript代码。这种方式的缺点在于，任何有决心的程序员都能够用全局搜索和替换工具轻松地打破这种保护，因为这只需把那些含义模糊的变量名字改成含义明确的变量名字即可。关于JAMMER的更多说明，请参见这里。 c）加密：有许多方案、工具能够有效地加密JavaScript代码。加密客户端JavaScript代码最主要的问题在于用来解密的脚本代码往往很轻易取得，导致对代码实施反向工程异常轻易。显然，这种方式不能阻止任何认真的程序员获取源代码。虽然我们可以用Java作为加密和解密过程的中间工具，但遗憾的是，Applet会给Web页面增加不必要的额外负荷，而且它会因为浏览器所用Java虚拟机版本的不同而无法正常运行。相对而言， DHTML却意味着迅速、小巧、通用和可移植。 一种新方式 在试验WML（Wireless Markup Language）时，我想到了一种保护客户端源代码的新方式。在基于ASP的WML页面中，服务器 端代码会有如下内容： < % Response.ContentType = "text/vnd.wap.wml" % > < ?xml version="1.0" encoding="iso-8859-1"? > < !DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml" > < wml > ...... 可以看到，我们首先发送了一个WML头，使得无线浏览器认为该ASP页面实际上是一个WML页面。这种技术同样可以用来保护JavaScript源文件（.js文件）。 Netscape随着JavaScript 1.2的发布引入了对JavaScript源文件的支持。大多数支持该版本JavaScript的浏览器都支持JavaScript源文件（Internet Explorer 3.0+，Netscape 3.0+以及Opera 5.0）。动态HTML（DHTML）由JavaScript和CSS混合构成。CSS样式使得开发者能够自由地在浏览器窗口中表现各种页面元素，而 JavaScript则提供了控制浏览器本身的必要功能。JavaScript是DHTML的要害组成部分。 下面我们通过例子来说明这种新的DHTML源代码保护方式。这个例子涉及三个文件：index.asp，js.asp以及 global.asa。global.asa定义了一个auth会话变量，该变量用于验证哀求JavaScript源文件的页面起源是否合法。这里选择使用会话变量的原因在于它用起来比较方便。 global.asa Sub Session_OnStart Session("auth") = False End Sub 我曾经试过用HTTP_REFERER系统变量来验证发出哀求的页面起源是否合法，后来发现这个变量可以通过telnet伪造，而且某些浏览器未能在运行时准确地显示出HTTP_REFERER变量。 index.asp < % Session("auth") = True Response.Expires = 0 Response.Expiresabsolute = Now() - 1 Response.AddHeader "pragma","no-cache" Response.AddHeader "cache-control","private" Response.CacheControl = "no-cache" % > < html > < head > < title >测试页面< /title > < script language="Javascript" type="text/javascript" SRC="js.asp" >< /script > < /head > < body > < script language="Javascript" >test();< /script > < br > < a href="index.asp" >reload< /a > < /body > < /html > 下面我们来分析一下index.asp。首先，程序把auth会话变量设置成了“true”，它表示哀求.js文件的页面应该被信任。 接下来的几个Response调用防止浏览器缓存index.asp页面。 一般地，在HTML文件中调用JavaScript源文件的语法如下： < script language="Javascript" src="yourscript.js" >< /script > 但在本例中，我们调用的却是一个ASP页面而不是JavaScript源文件： < script language="Javascript" type="text/javascript" SRC="js.asp" >< /script > 假如要遮掩应用正在哀求ASP页面这一事实，你可以把js.asp改名为index.asp（或者default.asp），然后把这个文件放到单独的目录之中，比如“/js/”，此时上面这行代码就改为： < script language="Javascript" type="text/javascript" SRC="/js/" >< /script > 这几乎能够疑惑任何企图获取JavaScript源文件的人了。不过，请不要忘记在IIS服务器配置中准确地设置默认页面文件的 名字。 js.asp < % IF Session("auth") = True THEN Response.ContentType = "application/x-javascript" Response.Expires = 0 Response.Expiresabsolute = Now() - 1 Response.AddHeader "pragma","no-cache" Response.AddHeader "cache-control","private" Response.CacheControl = "no-cache" Session("auth") = False % > function test(){ document.write(\\\'这是javascript函数的输出.\\\'); } < %ELSE% > < !--这些代码受版权保护。所有权利保留-- > < %END IF% > 下面我们来分析一下js.asp如何进行验证以及发送JavaScript代码。程序首先检查会话变量auth，看看哀求的起源是否合法。如是，则关闭浏览器缓存，重新设置会话变量，然后向浏览器发送JavaScript代码。假如对js.asp的哀求不是来自可靠的起源，会话变量auth是 false，程序只发送一个带有版权声明的空白页面。 其结果是，假如用户企图下载JavaScript源文件或者在另一个网站上使用JavaScript源文件，他得到的只是一个空白页面。这样，我们也就实现了对谁可以访问DHTML源文件的控制。 假如要在Web页面中保护页面实际内容的HTML代码，你可以在js.asp文件中创建一个函数，如下所示： function html(){ document.write(\\\'< html >< body >页面内容< /body >< /html > \\\'); } 然后，主页面只需简朴地调用一下html()即可构造出Web页面。这种页面只有在用户启用了浏览器的JavaScript支持之后才会显示。假如用户查看这种页面的源代码，他看到的只有一个函数调用，而不会看到函数调用所返回的源代码。 这种表现出两种（或更多）不同类型文件特征的ASP可以称为“混合ASP”。下面是JavaScript/ASP混合文件的一些特点： ●JavaScript源文件直接发向浏览器，未经缓存。 ●文件经过必要的验证，防止了用户下载源代码。 ●最终用户不能直接访问源代码。 上面的代码已经在Windows 98、Windows NT平台的Personal Web Server以及IIS 4上进行了测试，在下列浏览器上代码均能流畅地运行：Netscape 4.7，Internet Explorer 5，Netscape 6以及Opera 5.0。 局限和任何其他技术相同，本文所介绍的技术也有其固有的局限。 ▲ 会话变量： 在上面的例子中，我们使用会话变量验证JavaScript源文件调用的起源。假如网站的访问量异常高，这可能不是进行验证的最好方式。 每次用户访问Web页面或Web应用时都要创建一个会话变量。服务器保持会话唯一标识符的默认时间是20分钟。假如服务器同时要为大量访问者维持状态信息，你可以想象出服务器的负载会有多高。 解决这个问题主要有两种方式： ●在服务器上把会话超时时间设置得尽量小。此外，当代码已经发送给浏览器之后，调用Session.Abandon释放会话状态信息。这种方式适用于中小流量的网站。 ●对于高流量的网站，建议通过GUID/数据库结合维持会话状态的方式进行验证。 ▲ 内存分配： 大多数基于Mozilla的浏览器都用Spidermonkey JavaScript引擎解释执行JavaScript。这个引擎的长处包括：以解释方法执行代码（与编译方法相对应），动态垃圾收集机制（换句话说，自动释放内存空间避免内存漏洞吞噬计算机资源）。 试试下面这个操作：运行上面的例子。函数执行之后，进入URL地址栏，选中URL并敲Enter，你可以看到此时函数并不执行，浏览器显示了一个JavaScript错误。然而，假如你点击浏览器的刷新按钮，函数将正常执行。 下面是产生这种情况的原因：JavaScript函数执行之后，由于浏览器假定需要时这些代码仍然可以从缓存获得，于是它就释放了为 JavaScript保留的内存。然而，ASP代码禁止了浏览器缓存JavaScript代码。由于浏览器不能再引用内存中的函数，也不能再从缓存中获取函数代码，所以你就在按Enter键时看到了一个错误。 点击浏览器的刷新按钮时，浏览器将重新从服务器下载函数代码并执行。假如代码不再引用函数，则JavaScript引擎将释放函数。但有一种方式可以强制浏览器在内存中保留函数，即在程序执行期间始终激活对函数的引用。 ▲ 早期的/不兼容的浏览器： 毫无疑问，本文所介绍的方式不适合JavaScript版本早于1.2的浏览器。解决办法是编写一个预先进行检查的程序，由该程序检查用户浏览器是否和你的Web应用兼容。 ▲ 包截取： 理论上，只要企图窃取代码的人具有足够的决心，他可以在代码向浏览器发送时通过窃取数据包窃取代码。然而，这项工作所要耗费的时间和精力使得它几乎成为不可能的事情。而且，假如你想要获得百分之百安全的传输，还可以使用SSL。使用SSL唯一的缺点在于应用只能在支持SSL的浏览器上运行。 ■ 小结： “混合ASP”技术的应用当然不会局限于ASP和JavaScript源文件。在理论上，它可以在许多服务器端脚本语言环境中应用，比如CGI 或者PHP。此外，这种技术理论上还可以用于保护其他文件，如图形、声音和文档。例如，“混合ASP”文件完全可以起到图形文件的作用，详细方式是先验证哀求的起源，向浏览器发送准确的内容类型标识，然后从SQL数据库提取并发送BLOB字段的图形文件。它在这方面的应用可以说是没有止境的。 在未来的许多年里，JavaScript和DHTML仍将继承发展，并继承作为一种重要的Web开发工具而存在。W3C有望认可客户端编程工具的价值和重要性，并为了保护它而制定一个标准。 返回类别: 教程 上一教程: 数据库查询中的特别字符的问题 下一教程: 使用COOKIE来跟踪用户 您可以阅读与"巧用ASP技术保护DHTML源代码"相关的教程: · 保护ASP脚本源代码 · 解密ASP源代码 · 在ASP中用EASYMAILOBJECT组件处理EXCHANGE邮件源代码-读取邮件主题和大小 · 可以查看源代码的ASP程序 · ASP生成柱型体，折线图，饼图源代码 |
  |
| 快精灵印艺坊 版权所有 |
首页 会员中心在线印刷在线编辑付款方式索取样品设计指南连锁门店
|
||
