DHTML protecting Your DHTML Using ASP
by Jean-luc David
Categories:site Design, scripting
ARTICLE type:tutorial Reader Comments
ABSTRACT
Article Rating
Useful
Innovative
Informative
MB responses
Dynamic HTML allows developers a opportunity to create powerful the client Web applications that are Cross-browser compliant, Interactive and portable. Unfortunately publish to the Web your JavaScript code is insecure. Your hard work can be viewed, downloaded and copied. This article would describe a experimental innovative method of securing your DHTML code using server Authentication and Data streams ". The method in question would prevent the end user from directly accessing the source code.
Article Discussion Rate This Article Related Links Index Entries
ARTICLE
Abstract:
Dynamic HTML allows developers a opportunity to create powerful the client Web applications that are Cross-browser compliant, Interactive and portable. Unfortunately publish to the Web your JavaScript code is insecure. Your hard work can be viewed, downloaded and copied. If you are developing E-commerce applications, your business rules and practices the May is exposed to prying eyes.
Traditional means of protecting JavaScript usually involve scrambling or obfuscating the code. These methods are highly ineffectual against any determined code-hacker.
This article would describe a experimental innovative method of securing your DHTML code using server Authentication and Data streams ". The method in question would prevent the end user from directly accessing the source code.
Introduction:
The DHTML is fast becoming the de facto tool for creating powerful, Cross-browser on the web. Microsoft has rallied behind the development of the DOM (Document Object Model) and Netscape has pushed with its s Upport for the language and the release of the Netscape 6 browser. The power of the DHTML are based in part by its ability to programmatically control any fourth generation browser without the N Eed for additional plugins or executables.
As we know, the web is fundamentally a insecure medium. All client based development code (HTML, JavaScript Source Files and Style Sheets) typically downloads into the user ' s CAC He when they access your Web applications or Web pages. The end user can simply click ' View Source ' to view, analyze or copy your code. This is a basic limitation so we have all have to live with. Or do we?
I strongly feel that Web developers should is given the choice whether or not to share client their code. As your Web applications become more powerful and versatile, so does the need to protect your. Especially if your application is business oriented or your ' ve spent months working on a unique or groundbreaking DHTML app Lication.
Traditional protection techniques:
MSDN has published a excerpt of Wrox ' s Instant JavaScript book on their site that outlines a few options for protecting Y Our JavaScript.
Http://msdn.microsoft.com/library/partbook/instantj/privacyforscriptwriters.htm
The principal client JavaScript code protection schemes can is divided into the following categories:
A) The Microsoft Approach:microsoft has tackled the challenge of protecting client source code with the release of the ' Mi Crosoft Windows Script Engine Version 5.0. The source code is encoded (not encrypted) and filtered through an ActiveX layer.
Http://msdn.microsoft.com/library/periodic/period99/scriptengine.htm
The disadvantage of this approach was that the encoding can only be deciphered with Microsoft's Internet Explorer 5.0+. They readily admit the encoding process is not entirely foolproof. If you are are using any and browser (including earlier releases of Internet Explorer), you won't be able to access the S Cript through the browser.
b) Code Obfuscation:s
