Colt blogs about Obfuscating Web Pages using a commercial product.
The fact is, because the script is interpreted at runtime, the scripting engine has to be able to decode the encrpyted data and needs information on how to do this. With the way the HTTP protocol works and current scripting technologies, if the scripting engine can get this information, so can the hacker. Even the Microsoft ScriptEncoder for encrypting VBScript has been broken.
Only server side code can be protected (BTW, have you locked down your webserver using IPSEC? If not, you should consider doing so!)
WebControls generally render the Id attribute as the ClientId value so that they can be unique from a DOM perspective. The Calendar Control does not seem to follow this.
For example, if you have a Calendar Control Calendar1 in an ascx page WebUserControl, instead of rendering the Id as WebUserControl1_Calendar1 on the parent page, it simply renders it as Calendar1.
When developing a custom webcontrol that “looks at” other controls, it becomes impossible to use the getElementById property on the the calendar control as the ID rendered is different from what you are expecting.
The workaround I used is to embed the Calendar control in a Panel control and use the ID of the Panel control. I realize you could hard code values instead of doing this but my webcontrol needs to use the getElementById method to get different controls on a container.
Is there a reason behind this?