Options
Clarify Web Application protection please.
manlyboy
Posts: 27 Bronze 2
The following is an excerpt from the 'How To' protect a web application...
My compiled output creates a dll for 'App_global.asax' as well as one for each page, each of which starts with 'App_Web_<pagename>xxx'. It also creates several dll's for themes which I'm not worried about as well as the main dll which is named '<MyWebSitesName>.dll'.
My confusion is that the directions state NOT to create SA projects for the 'App_Web_xxx' files which in my case would cover each of the individual pages. It then goes on to indicate that the main DLL is named 'App_web_xxx.dll' which it obviously isn't.
The final point confuses me more as it infers that the individual page dll's should not be copied to the new web directory.
I have sa built App_global.asax.dll as well as the <MyWebSitesName>.dll and the web site works fine.
Do the individual pages need building with sa projects or is it OK just to copy the original dll's and use them.
· Use Aspnet_Compiler to create pre-compiled code for the website
(aspnet_compiler -v "/" -d -p "c:\mywebsite" "c:\mynewwebsite")
· Open the dependent DLLs (not App_Web_xxx.dll) and create an SA project for each
· Set up error reporting to report silently
· Build the DLL into a new folder in a "bin" subfolder (c:\mynewSAwebsite\bin)
· Open the main DLL in a new SmartAssembly project (App_Web_xxx.dll)
· Set up error reporting as for the dependent DLLs, but do not merge or embed the dependencies.
· Copy all of the files that are not DLLs from the original compiled website to the one you just created
My compiled output creates a dll for 'App_global.asax' as well as one for each page, each of which starts with 'App_Web_<pagename>xxx'. It also creates several dll's for themes which I'm not worried about as well as the main dll which is named '<MyWebSitesName>.dll'.
My confusion is that the directions state NOT to create SA projects for the 'App_Web_xxx' files which in my case would cover each of the individual pages. It then goes on to indicate that the main DLL is named 'App_web_xxx.dll' which it obviously isn't.
The final point confuses me more as it infers that the individual page dll's should not be copied to the new web directory.
I have sa built App_global.asax.dll as well as the <MyWebSitesName>.dll and the web site works fine.
Do the individual pages need building with sa projects or is it OK just to copy the original dll's and use them.
Comments
In my example, there was only one App_Web_<random>.dll file produced by aspnet_compiler. Since this contains the ASP namespace, I assumed this would be the "entry point" for the web application and there would only be one.
So the idea was to process all of the codebehind DLLs first, then the App_Web...dll.
My example also only produced one codebehind DLL for all pages (App_Code.dll).
If the behavior of aspnet_compiler has changed, we'll have to spend another day trying to reverse-engineer what the compiler is doing and write a new article because I can't say why you have all of these DLLs.
If I don't use the -fixednames argument, the compiler creates fewer dll's instead of one for each page. I used -fixednames because your article indicates I need to sa process each one and therefore -fixednames is essential.
I doubt whether the aspnet_compiler.exe behavour has changed.
The individual page dll's appear to contain the aspx page and not the code behind. It is of course the code behind I'm more worried about anyhow.
The question is, can SA obfuscate the individual aspx pages? It doesn't seem to be able to.
fixednames makes the compiler produce a separate assembly for every page... if this means what it says then you can run SA on every DLL because an assembly by definition contains managed code.
I guess this should be okay...
Can you give it a try and if it doesn't work let me know - I'll have to put some lab time in my schedule to try to reproduce any problem you may have.
<pageName>.aspx.xxxxx.compiled
App_Web_<pageName>.aspx.xxxxx.dll
[the xxxxx is a hash code and is the same for all the files]
as well as:
App_global.asax.dll
<WebsiteName>.dll
It also will produce dll's for any other dependent dll's in the project.
The <pageName>.aspx.xxxxx.dll is the compiled web page only. That is, the code behind page (.cs) is not compiled into this dll. All the .cs files are compiled into one dll which is the <WebsiteName>.dll .
Using Visual Build, I use SA on the App.global.asax.dll followed by the individual web page dll's and finally the dependant dll's and the <WebsiteName>.dll .
Some of the pages can be viewed fine however others cannot and SA generates the following error reports. The stack trace reads:
Notwithstanding the above, I have been successful in generating the individual page files on an ad-hoc basis and viewing them successfully. I will do some more testing however this is becoming very time consuming
After doing the above, I then ran SA on 3 more pages as well as the <WebsiteName>.dll. I did replace the dll's they produced and tested the website on each SA build/dll replacement without problem. I assume that providing the App_global.aspx.dll generated by SA is in the original directory before processing any more SA builds, then it won't matter in which order you SA protect the rest.
If I find any more problems I'll post them here.
Glad you understand what happened but unfortunately I have run into more complications...
There are two 'page' dll's that throw the same error reported above no matter in what order I SA protect them. They are the App_Web_masterpage.master.xxxx.dll and the App_Web_default.aspx.xxxx.dll pages. Unfortunately they are the two most important.
Is there some way I can achieve my goal?
This may take a day or two. Hopefully I will encounter the same problem.
Also, please ensure that it works before you process it with smartassembly. I am not entirely sure what the -fixednames option does and the documentation says something about it breaking batch compilation, but I don't understand at all what Microsoft are talking about with "batch compilation" as this aspnet_compiler is supposed to do all of the compilation before you deploy the website.
The article doesn't mention needing a DLL for each page, just that you should process all of the DLLs... Does it work if you don't use -fixednames?
Are you trying to incorporate error reporting into the web app? What other features are you trying to incorporate?
No but it's impossible to automate the process if you don't.
If I don't use -fixednames then each time the program is pre-compiled, the dll names change. I'm useless with regexes so I can't see how I can automate SA processing when the source file name changes all the time.
Following this logic, you may also want to try setting the web application to run with full trust in the web.config.