I have run into an issue that when my web application's web.config compilation debug is set to true I am getting a vulnerability error on a security scan.
What I want to determine is if there is a way to have some type of web.config conditional block change the debug setting to use the correct value on debug builds and release builds. I have read that setting the property in each web page itself will do this and don't know if this is in fact true and are there any problems with this?
I would suggest <deployment retail=”true”/>.
You put this element into your machine.config on the production server and it overrides debug=”true” in your web.config and pages. In other words, you can happily use the debug and trace functionality on your developer machines but can be sure it is turned off on the production server. Scott Guthrie recommends this as best practice.
Related
Now this is interesting!
I just noticed that exceptions in my MVC Views have line-numbers in the stack trace! Which means - my views are compiled with PDB.
I looked at the "Temporary ASP.NET Files" folder on my server - and yes, there are PDB files for every view.
I have <compilation debug="false"/> in my web.config.
Why is this happening and how do I disable that? This is the production server, so I would like to disable the pdb-generation.
I checked my "web.config", "Views/web.config", "machine.config", default "web.config" in windir%\Microsoft.NET\Framework64\[version]\config\ - I think I haven't found any suspicious compiler options there... Where do I look?
Or am I just wasting my time and this is the default option that cannot be changed?
PS. More info, just in case: this is an MVC 4 app, the Views are written in Razor.
Found it!!
Seems like this is the default setting for Razor - it is always compiled with DEBUG option and you can't change it - but I think I found the solution.
Adding this to your machine.config seem to fix the issue:
<configuration>
<system.web>
<deployment retail="true"/>
<system.web>
</configuration>
At least I don't see any more .pdb's in my "Temp ASP.NET Files".
More info about this flag on ScottGu's blog: http://weblogs.asp.net/scottgu/Don_1920_t-run-production-ASP.NET-Applications-with-debug_3D001D20_true_1D20_-enabled
is it possible to set a default page to run when starting debugging? In Visual Studio you can set the default page either through the context menu in Solution Explorer or in the project properties. I did not find something like that in MonoDevelop.
When I am starting debugging the browser will always navigate to the root of the application.
http://localhost:8080
Because there is no default page set in XSP for this application I get an error and always have to correct it manually.
http://localhost:8080/home.aspx
Thanks for your help.
I found a solution. I did not find the xsp.exe.config but it also works when you add the setting either globally in machine.config (residing in /etc/mono/[version]) or by creating a web.config file in your applications root. The values are comma separated.
<appSettings>
<add key="MonoServerDefaultIndexFiles" value="Home.aspx, home.aspx" />
</appSettings>
The help page http://www.mono-project.com/Config does not tell you that a appSettings section is allowed, but I think that the documentation is just incomplete. For example appSettings are used here http://www.mono-project.com/ASP.NET_Settings_Mapping#Inhibiting_the_settings_mapping too.
I'm trying to avoid having compile errors block the whole ASP site while we are in development. That is, I want each page to compile on first run instead of the whole site so that compile errors do not show up globally. That can be danged annoying when a dev takes off for lunch after saving with a systnax bleherror.
I've tried adding this to ye olde web config (changed from default "Always"):
<pages compilationMode="Auto" controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID">
This did not have the desired effect. What can I change in the webconfig or using IIS to disable precompilation?
Web.config
<compilation batch="false" />
Indicates whether batching is supported.
If True, eliminates the delay caused by the compilation required when you access a file for the first time. When this attribute is set to True, ASP.NET precompiles all the uncompiled files in a batch mode, which causes an even longer delay the first time the files are compiled. However, after this initial delay, the compilation delay is eliminated on subsequent access of the file.
The default is True.
https://msdn.microsoft.com/library/s10awwz0.aspx
In IIS 7
To Use the UI
Open IIS Manager and navigate to the level you want to manage. For information about opening IIS Manager, see Open IIS Manager (IIS 7). For information about navigating to locations in the UI, see Navigation in IIS Manager (IIS 7).
In Features View, double-click .NET Compilation.
On the .NET Compilation page, edit settings as necessary.
When finished, click Apply in the Actions pane.
http://technet.microsoft.com/en-us/library/cc725812(v=ws.10).aspx
I have published an ASP.NET MVC3 site. It runs great. However, looking back at my web.config file, I was not sure if some of the values I used are correct for publishing versus for developing. These configurations are in the <system.web> section.
...
<system.web>
<httpRuntime requestValidationMode="2.0" executionTimeout="200" maxRequestLength="20000000"/>
<compilation debug="true" targetFramework="4.0">
...
I read here ( http://msdn.microsoft.com/en-us/library/e1f13641.aspx ) that using debug=true in compilation will disregard the executionTimeout of 200, and use a default value of 110. This seems to be the case, and the site is setup to allow very large amounts of files to be uploaded all at once. However, with only 110 seconds, not much can be uploaded.
My question is this: Is the correct setting to publish a live site for debug "false"? In addition, is requestValidationMode="2.0" still safe to use considering asp.net is now on version 4 (soon to be 4.5)?
Validationmode 2.0 is not the framework version and can stay like that.
Put debug=false and you are fine.
requestValidationMode... As far as I'm aware, this has to be set to 2.0 if you want to allow special characters (<, >, % etc.) in request data to pass ASP.NET's request validation at all. requestValidationMode="2.0" means "only enforce validation on pages (i.e. .aspx), rather than on every request (as was introduced in 4.0). That allows ASP.NET MVC to take over the validation - and hence also lets you turn it off for specific requests.
Is it safe? It is, if you've made sure that any actions or controllers that have [ValidateInput(false)] applied or models with [AllowHtml] have been properly secured against attacks. Imran Baloch has a full explanation here.
And yes, debug should be "false" for several reasons, including performance and memory usage. Also, debug="true" changes the default cache policy for static files to never cache the files in the browser, meaning tons of redundant requests for scripts, CSS etc.
As for the image upload, other than the suggestions given, check in Event Viewer that it's not really the application pool recycling for one reason or other, rather than an execution timeout.
We have a .NET 2.0 application which we normally run on IIS6, and used to run fine on IIS7, but recently after installing SP1 for Vista IIS7 seems to be choking on a line in the Web.Config file:
<system.web AllowLocation="true">
Is it safe to remove the AllowLocation attribute? What does this attribute do?
From MSDN:
When set to false, the AllowLocation property indicates that the section is accessed by native-code readers. Therefore, the use of the location attribute is not allowed, because the native-code readers do not support the concept of location.
The default value is true, so you should be able to remove it with no effect on your application.
Having this set to true should enable any <location> sections in your web.config, so you should be fine to remove it if there's none in there.