A potentially dangerous Request.Form value was detected from the client - asp.net

Every time a user posts something containing < or > in a page in my web application, I get this exception thrown.
I don't want to go into the discussion about the smartness of throwing an exception or crashing an entire web application because somebody entered a character in a text box, but I am looking for an elegant way to handle this.
Trapping the exception and showing
An error has occurred please go back and re-type your entire form again, but this time please do not use <
doesn't seem professional enough to me.
Disabling post validation (validateRequest="false") will definitely avoid this error, but it will leave the page vulnerable to a number of attacks.
Ideally: When a post back occurs containing HTML restricted characters, that posted value in the Form collection will be automatically HTML encoded.
So the .Text property of my text-box will be something & lt; html & gt;
Is there a way I can do this from a handler?

I think you are attacking it from the wrong angle by trying to encode all posted data.
Note that a "<" could also come from other outside sources, like a database field, a configuration, a file, a feed and so on.
Furthermore, "<" is not inherently dangerous. It's only dangerous in a specific context: when writing strings that haven't been encoded to HTML output (because of XSS).
In other contexts different sub-strings are dangerous, for example, if you write a user-provided URL into a link, the sub-string "javascript:" may be dangerous. The single quote character on the other hand is dangerous when interpolating strings in SQL queries, but perfectly safe if it is a part of a name submitted from a form or read from a database field.
The bottom line is: you can't filter random input for dangerous characters, because any character may be dangerous under the right circumstances. You should encode at the point where some specific characters may become dangerous because they cross into a different sub-language where they have special meaning. When you write a string to HTML, you should encode characters that have special meaning in HTML, using Server.HtmlEncode. If you pass a string to a dynamic SQL statement, you should encode different characters (or better, let the framework do it for you by using prepared statements or the like)..
When you are sure you HTML-encode everywhere you pass strings to HTML, then set ValidateRequest="false" in the <%# Page ... %> directive in your .aspx file(s).
In .NET 4 you may need to do a little more. Sometimes it's necessary to also add <httpRuntime requestValidationMode="2.0" /> to web.config (reference).

There's a different solution to this error if you're using ASP.NET MVC:
ASP.NET MVC – pages validateRequest=false doesn’t work?
Why is ValidateInput(False) not working?
ASP.NET MVC RC1, VALIDATEINPUT, A POTENTIAL DANGEROUS REQUEST AND THE PITFALL
C# sample:
[HttpPost, ValidateInput(false)]
public ActionResult Edit(FormCollection collection)
{
// ...
}
Visual Basic sample:
<AcceptVerbs(HttpVerbs.Post), ValidateInput(False)> _
Function Edit(ByVal collection As FormCollection) As ActionResult
...
End Function

In ASP.NET MVC (starting in version 3), you can add the AllowHtml attribute to a property on your model.
It allows a request to include HTML markup during model binding by skipping request validation for the property.
[AllowHtml]
public string Description { get; set; }

If you are on .NET 4.0 make sure you add this in your web.config file inside the <system.web> tags:
<httpRuntime requestValidationMode="2.0" />
In .NET 2.0, request validation only applied to aspx requests. In .NET 4.0 this was expanded to include all requests. You can revert to only performing XSS validation when processing .aspx by specifying:
requestValidationMode="2.0"
You can disable request validate entirely by specifying:
validateRequest="false"

For ASP.NET 4.0, you can allow markup as input for specific pages instead of the whole site by putting it all in a <location> element. This will make sure all your other pages are safe. You do NOT need to put ValidateRequest="false" in your .aspx page.
<configuration>
...
<location path="MyFolder/.aspx">
<system.web>
<pages validateRequest="false" />
<httpRuntime requestValidationMode="2.0" />
</system.web>
</location>
...
</configuration>
It is safer to control this inside your web.config, because you can see at a site level which pages allow markup as input.
You still need to programmatically validate input on pages where request validation is disabled.

The previous answers are great, but nobody said how to exclude a single field from being validated for HTML/JavaScript injections. I don't know about previous versions, but in MVC3 Beta you can do this:
[HttpPost, ValidateInput(true, Exclude = "YourFieldName")]
public virtual ActionResult Edit(int id, FormCollection collection)
{
...
}
This still validates all the fields except for the excluded one. The nice thing about this is that your validation attributes still validate the field, but you just don't get the "A potentially dangerous Request.Form value was detected from the client" exceptions.
I've used this for validating a regular expression. I've made my own ValidationAttribute to see if the regular expression is valid or not. As regular expressions can contain something that looks like a script I applied the above code - the regular expression is still being checked if it's valid or not, but not if it contains scripts or HTML.

In ASP.NET MVC you need to set requestValidationMode="2.0" and validateRequest="false" in web.config, and apply a ValidateInput attribute to your controller action:
<httpRuntime requestValidationMode="2.0"/>
<configuration>
<system.web>
<pages validateRequest="false" />
</system.web>
</configuration>
and
[Post, ValidateInput(false)]
public ActionResult Edit(string message) {
...
}

You can HTML encode text box content, but unfortunately that won't stop the exception from happening. In my experience there is no way around, and you have to disable page validation. By doing that you're saying: "I'll be careful, I promise."

The answer to this question is simple:
var varname = Request.Unvalidated["parameter_name"];
This would disable validation for the particular request.

You can catch that error in Global.asax. I still want to validate, but show an appropriate message. On the blog listed below, a sample like this was available.
void Application_Error(object sender, EventArgs e)
{
Exception ex = Server.GetLastError();
if (ex is HttpRequestValidationException)
{
Response.Clear();
Response.StatusCode = 200;
Response.Write(#"[html]");
Response.End();
}
}
Redirecting to another page also seems like a reasonable response to the exception.
http://www.romsteady.net/blog/2007/06/how-to-catch-httprequestvalidationexcep.html

For MVC, ignore input validation by adding
[ValidateInput(false)]
above each Action in the Controller.

Please bear in mind that some .NET controls will automatically HTML encode the output. For instance, setting the .Text property on a TextBox control will automatically encode it. That specifically means converting < into <, > into > and & into &. So be wary of doing this...
myTextBox.Text = Server.HtmlEncode(myStringFromDatabase); // Pseudo code
However, the .Text property for HyperLink, Literal and Label won't HTML encode things, so wrapping Server.HtmlEncode(); around anything being set on these properties is a must if you want to prevent <script> window.location = "http://www.google.com"; </script> from being output into your page and subsequently executed.
Do a little experimenting to see what gets encoded and what doesn't.

In the web.config file, within the tags, insert the httpRuntime element with the attribute requestValidationMode="2.0". Also add the validateRequest="false" attribute in the pages element.
Example:
<configuration>
<system.web>
<httpRuntime requestValidationMode="2.0" />
</system.web>
<pages validateRequest="false">
</pages>
</configuration>

If you don't want to disable ValidateRequest you need to implement a JavaScript function in order to avoid the exception. It is not the best option, but it works.
function AlphanumericValidation(evt)
{
var charCode = (evt.charCode) ? evt.charCode : ((evt.keyCode) ? evt.keyCode :
((evt.which) ? evt.which : 0));
// User type Enter key
if (charCode == 13)
{
// Do something, set controls focus or do anything
return false;
}
// User can not type non alphanumeric characters
if ( (charCode < 48) ||
(charCode > 122) ||
((charCode > 57) && (charCode < 65)) ||
((charCode > 90) && (charCode < 97))
)
{
// Show a message or do something
return false;
}
}
Then in code behind, on the PageLoad event, add the attribute to your control with the next code:
Me.TextBox1.Attributes.Add("OnKeyPress", "return AlphanumericValidation(event);")

Another solution is:
protected void Application_Start()
{
...
RequestValidator.Current = new MyRequestValidator();
}
public class MyRequestValidator: RequestValidator
{
protected override bool IsValidRequestString(HttpContext context, string value, RequestValidationSource requestValidationSource, string collectionKey, out int validationFailureIndex)
{
bool result = base.IsValidRequestString(context, value, requestValidationSource, collectionKey, out validationFailureIndex);
if (!result)
{
// Write your validation here
if (requestValidationSource == RequestValidationSource.Form ||
requestValidationSource == RequestValidationSource.QueryString)
return true; // Suppress error message
}
return result;
}
}

It seems no one has mentioned the below yet, but it fixes the issue for me. And before anyone says yeah it's Visual Basic... yuck.
<%# Page Language="vb" AutoEventWireup="false" CodeBehind="Example.aspx.vb" Inherits="Example.Example" **ValidateRequest="false"** %>
I don't know if there are any downsides, but for me this worked amazing.

I guess you could do it in a module; but that leaves open some questions; what if you want to save the input to a database? Suddenly because you're saving encoded data to the database you end up trusting input from it which is probably a bad idea. Ideally you store raw unencoded data in the database and the encode every time.
Disabling the protection on a per page level and then encoding each time is a better option.
Rather than using Server.HtmlEncode you should look at the newer, more complete Anti-XSS library from the Microsoft ACE team.

If you're using framework 4.0 then the entry in the web.config (<pages validateRequest="false" />)
<configuration>
<system.web>
<pages validateRequest="false" />
</system.web>
</configuration>
If you're using framework 4.5 then the entry in the web.config (requestValidationMode="2.0")
<system.web>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" requestValidationMode="2.0"/>
</system.web>
If you want for only single page then, In you aspx file you should put the first line as this :
<%# Page EnableEventValidation="false" %>
if you already have something like <%# Page so just add the rest => EnableEventValidation="false" %>
I recommend not to do it.

In ASP.NET, you can catch the exception and do something about it, such as displaying a friendly message or redirect to another page... Also there is a possibility that you can handle the validation by yourself...
Display friendly message:
protected override void OnError(EventArgs e)
{
base.OnError(e);
var ex = Server.GetLastError().GetBaseException();
if (ex is System.Web.HttpRequestValidationException)
{
Response.Clear();
Response.Write("Invalid characters."); // Response.Write(HttpUtility.HtmlEncode(ex.Message));
Response.StatusCode = 200;
Response.End();
}
}

I found a solution that uses JavaScript to encode the data, which is decoded in .NET (and doesn't require jQuery).
Make the textbox an HTML element (like textarea) instead of an ASP one.
Add a hidden field.
Add the following JavaScript function to your header.
function boo() {
targetText = document.getElementById("HiddenField1");
sourceText = document.getElementById("userbox");
targetText.value = escape(sourceText.innerText);
}
In your textarea, include an onchange that calls boo():
<textarea id="userbox" onchange="boo();"></textarea>
Finally, in .NET, use
string val = Server.UrlDecode(HiddenField1.Value);
I am aware that this is one-way - if you need two-way you'll have to get creative, but this provides a solution if you cannot edit the web.config
Here's an example I (MC9000) came up with and use via jQuery:
$(document).ready(function () {
$("#txtHTML").change(function () {
var currentText = $("#txtHTML").text();
currentText = escape(currentText); // Escapes the HTML including quotations, etc
$("#hidHTML").val(currentText); // Set the hidden field
});
// Intercept the postback
$("#btnMyPostbackButton").click(function () {
$("#txtHTML").val(""); // Clear the textarea before POSTing
// If you don't clear it, it will give you
// the error due to the HTML in the textarea.
return true; // Post back
});
});
And the markup:
<asp:HiddenField ID="hidHTML" runat="server" />
<textarea id="txtHTML"></textarea>
<asp:Button ID="btnMyPostbackButton" runat="server" Text="Post Form" />
This works great. If a hacker tries to post via bypassing JavaScript, they they will just see the error. You can save all this data encoded in a database as well, then unescape it (on the server side), and parse & check for attacks before displaying elsewhere.

Cause
ASP.NET by default validates all input controls for potentially unsafe contents that can lead to cross-site scripting (XSS) and SQL injections. Thus it disallows such content by throwing the above exception. By default it is recommended to allow this check to happen on each postback.
Solution
On many occasions you need to submit HTML content to your page through Rich TextBoxes or Rich Text Editors. In that case you can avoid this exception by setting the ValidateRequest tag in the #Page directive to false.
<%# Page Language="C#" AutoEventWireup="true" ValidateRequest = "false" %>
This will disable the validation of requests for the page you have set the ValidateRequest flag to false. If you want to disable this, check throughout your web application; you’ll need to set it to false in your web.config <system.web> section
<pages validateRequest ="false" />
For .NET 4.0 or higher frameworks you will need to also add the following line in the <system.web> section to make the above work.
<httpRuntime requestValidationMode = "2.0" />
That’s it. I hope this helps you in getting rid of the above issue.
Reference by: ASP.Net Error: A potentially dangerous Request.Form value was detected from the client

The other solutions here are nice, however it's a bit of a royal pain in the rear to have to apply [AllowHtml] to every single Model property, especially if you have over 100 models on a decent sized site.
If like me, you want to turn this (IMHO pretty pointless) feature off site wide you can override the Execute() method in your base controller (if you don't already have a base controller I suggest you make one, they can be pretty useful for applying common functionality).
protected override void Execute(RequestContext requestContext)
{
// Disable requestion validation (security) across the whole site
ValidateRequest = false;
base.Execute(requestContext);
}
Just make sure that you are HTML encoding everything that is pumped out to the views that came from user input (it's default behaviour in ASP.NET MVC 3 with Razor anyway, so unless for some bizarre reason you are using Html.Raw() you shouldn't require this feature.

Disable the page validation if you really need the special characters like, >, , <, etc. Then ensure that when the user input is displayed, the data is HTML-encoded.
There is a security vulnerability with the page validation, so it can be bypassed. Also the page validation shouldn't be solely relied on.
See: http://web.archive.org/web/20080913071637/http://www.procheckup.com:80/PDFs/bypassing-dot-NET-ValidateRequest.pdf

I was getting this error too.
In my case, a user entered an accented character á in a Role Name (regarding the ASP.NET membership provider).
I pass the role name to a method to grant Users to that role and the $.ajax post request was failing miserably...
I did this to solve the problem:
Instead of
data: { roleName: '#Model.RoleName', users: users }
Do this
data: { roleName: '#Html.Raw(#Model.RoleName)', users: users }
#Html.Raw did the trick.
I was getting the Role name as HTML value roleName="Cadastro bás". This value with HTML entity á was being blocked by ASP.NET MVC. Now I get the roleName parameter value the way it should be: roleName="Cadastro Básico" and ASP.NET MVC engine won't block the request anymore.

You could also use JavaScript's escape(string) function to replace the special characters. Then server side use Server.URLDecode(string) to switch it back.
This way you don't have to turn off input validation and it will be more clear to other programmers that the string may have HTML content.

I ended up using JavaScript before each postback to check for the characters you didn't want, such as:
<asp:Button runat="server" ID="saveButton" Text="Save" CssClass="saveButton" OnClientClick="return checkFields()" />
function checkFields() {
var tbs = new Array();
tbs = document.getElementsByTagName("input");
var isValid = true;
for (i=0; i<tbs.length; i++) {
if (tbs(i).type == 'text') {
if (tbs(i).value.indexOf('<') != -1 || tbs(i).value.indexOf('>') != -1) {
alert('<> symbols not allowed.');
isValid = false;
}
}
}
return isValid;
}
Granted my page is mostly data entry, and there are very few elements that do postbacks, but at least their data is retained.

You can use something like:
var nvc = Request.Unvalidated().Form;
Later, nvc["yourKey"] should work.

As long as these are only "<" and ">" (and not the double quote itself) characters and you're using them in context like <input value="this" />, you're safe (while for <textarea>this one</textarea> you would be vulnerable of course). That may simplify your situation, but for anything more use one of other posted solutions.

If you're just looking to tell your users that < and > are not to be used BUT, you don't want the entire form processed/posted back (and lose all the input) before-hand could you not simply put in a validator around the field to screen for those (and maybe other potentially dangerous) characters?

You can automatically HTML encode field in custom Model Binder. My solution some different, I put error in ModelState and display error message near the field. It`s easy to modify this code for automatically encode
public class AppModelBinder : DefaultModelBinder
{
protected override object CreateModel(ControllerContext controllerContext, ModelBindingContext bindingContext, Type modelType)
{
try
{
return base.CreateModel(controllerContext, bindingContext, modelType);
}
catch (HttpRequestValidationException e)
{
HandleHttpRequestValidationException(bindingContext, e);
return null; // Encode here
}
}
protected override object GetPropertyValue(ControllerContext controllerContext, ModelBindingContext bindingContext,
PropertyDescriptor propertyDescriptor, IModelBinder propertyBinder)
{
try
{
return base.GetPropertyValue(controllerContext, bindingContext, propertyDescriptor, propertyBinder);
}
catch (HttpRequestValidationException e)
{
HandleHttpRequestValidationException(bindingContext, e);
return null; // Encode here
}
}
protected void HandleHttpRequestValidationException(ModelBindingContext bindingContext, HttpRequestValidationException ex)
{
var valueProviderCollection = bindingContext.ValueProvider as ValueProviderCollection;
if (valueProviderCollection != null)
{
ValueProviderResult valueProviderResult = valueProviderCollection.GetValue(bindingContext.ModelName, skipValidation: true);
bindingContext.ModelState.SetModelValue(bindingContext.ModelName, valueProviderResult);
}
string errorMessage = string.Format(CultureInfo.CurrentCulture, "{0} contains invalid symbols: <, &",
bindingContext.ModelMetadata.DisplayName);
bindingContext.ModelState.AddModelError(bindingContext.ModelName, errorMessage);
}
}
In Application_Start:
ModelBinders.Binders.DefaultBinder = new AppModelBinder();
Note that it works only for form fields. Dangerous value not passed to controller model, but stored in ModelState and can be redisplayed on form with error message.
Dangerous chars in URL may be handled this way:
private void Application_Error(object sender, EventArgs e)
{
Exception exception = Server.GetLastError();
HttpContext httpContext = HttpContext.Current;
HttpException httpException = exception as HttpException;
if (httpException != null)
{
RouteData routeData = new RouteData();
routeData.Values.Add("controller", "Error");
var httpCode = httpException.GetHttpCode();
switch (httpCode)
{
case (int)HttpStatusCode.BadRequest /* 400 */:
if (httpException.Message.Contains("Request.Path"))
{
httpContext.Response.Clear();
RequestContext requestContext = new RequestContext(new HttpContextWrapper(Context), routeData);
requestContext.RouteData.Values["action"] ="InvalidUrl";
requestContext.RouteData.Values["controller"] ="Error";
IControllerFactory factory = ControllerBuilder.Current.GetControllerFactory();
IController controller = factory.CreateController(requestContext, "Error");
controller.Execute(requestContext);
httpContext.Server.ClearError();
Response.StatusCode = (int)HttpStatusCode.BadRequest /* 400 */;
}
break;
}
}
}
ErrorController:
public class ErrorController : Controller
{
public ActionResult InvalidUrl()
{
return View();
}
}

Related

Alternative to Server.Transfer in ASP.NET Core

I am migrating an ASP.NET application to ASP.NET Core and they have some calls to HttpServerUtility.Transfer(string path). However, HttpServerUtility does not exist in ASP.NET Core.
Is there an alternative that I can use? Or is Response.Redirect the only option I have?
I want to maintain the same behaviour as the old application as much as possible since there is a difference in between Server.Transfer and Response.Redirect.
I see some options for you, depending on your case:
Returning another View: So just the HTML. See answer of Muqeet Khan
Returning another method of the same controller: This allows also the execution of the business logic of the other action. Just write something like return MyOtherAction("foo", "bar").
Returning an action of another controller: See the answer of Ron C. I am a bit in troubles with this solution since it omits the whole middleware which contains like 90% of the logic of ASP.NET Core (like security, cookies, compression, ...).
Routing style middleware: Adding a middleware similar to what routing does. In this case your decision logic needs to be evaluated there.
Late re-running of the middleware stack: You essentially need to re-run a big part of the stack. I believe it is possible, but have not seen a solution yet. I have seen a presentation of Damian Edwards (PM for ASP.NET Core) where he hosted ASP.NET Core without Kestrel/TCPIP usage just for rendering HTML locally in a browser. That you could do. But that is a lot of overload.
A word of advice: Transfer is dead ;). Differences like that is the reason for ASP.NET Core existence and performance improvements. That is bad for migration but good for the overall platform.
You are correct. Server.Transfer and Server.Redirect are quite different. Server.Transfer executes a new page and returns it's results to the browser but does not inform the browser that it returned a different page. So in such a case the browser url will show the original url requested but the contents will come from some other page. This is quite different than doing a Server.Redirect which will instruct the browser to request the new page. In such a case the url displayed in the browser will change to show the new url.
To do the equivalent of a Server.Transfer in Asp.Net Core, you need to update the Request.Path and Request.QueryString properties to point to the url you want to transfer to and you need to instantiate the controller that handles that url and call it's action method. I have provided full code below to illustrate this.
page1.html
<html>
<body>
<h1>Page 1</h1>
</body>
</html>
page2.html
<html>
<body>
<h1>Page 2</h1>
</body>
</html>
ExampleTransferController.cs
using Microsoft.AspNetCore.Diagnostics;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
namespace App.Web.Controllers {
public class ExampleTransferController: Controller {
public ExampleTransferController() {
}
[Route("/example-transfer/page1")]
public IActionResult Page1() {
bool condition = true;
if(condition) {
//Store the original url in the HttpContext items
//so that it's available to the app.
string originalUrl = $"{HttpContext.Request.Scheme}://{HttpContext.Request.Host}{HttpContext.Request.Path}{HttpContext.Request.QueryString}";
HttpContext.Items.Add("OriginalUrl", originalUrl);
//Modify the request to indicate the url we want to transfer to
string newPath = "/example-transfer/page2";
string newQueryString = "";
HttpContext.Request.Path = newPath;
HttpContext.Request.QueryString = new QueryString(newQueryString);
//Now call the action method for that new url
//Note that instantiating the controller for the new action method
//isn't necessary if the action method is on the same controller as
//the action method for the original request but
//I do it here just for illustration since often the action method you
//may want to call will be on a different controller.
var controller = new ExampleTransferController();
controller.ControllerContext = new ControllerContext(this.ControllerContext);
return controller.Page2();
}
return View();
}
[Route("/example-transfer/page2")]
public IActionResult Page2() {
string originalUrl = HttpContext.Items["OriginalUrl"] as string;
bool requestWasTransfered = (originalUrl != null);
return View();
}
}
}
Placing the original url in HttpContext.Items["OriginalUrl"] isn't strictly necessary but doing so makes it easy for the end page to know if it's responding to a transfer and if so what the original url was.
I can see this is a fairly old thread. I don't know when URL Rewriting was added to .Net Core but the answer is to rewrite the URL in the middleware, it's not a redirect, does not return to the server, does not change the url in the browser address bar, but does change the route.
resources:
https://weblog.west-wind.com/posts/2020/Mar/13/Back-to-Basics-Rewriting-a-URL-in-ASPNET-Core
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/url-rewriting?view=aspnetcore-5.0
I believe you are looking for a "named view" return in MVC. Like so,
[HttpPost]
public ActionResult Index(string Name)
{
ViewBag.Message = "Some message";
//Like Server.Transfer() in Asp.Net WebForm
return View("MyIndex");
}
The above will return that particular view. If you have a condition that governs the view details you can do that too.
I know that this is a very old question, but if someone uses Razor Pages and is looking to a Server.Transfer alternative (or a way to return a different view depending on a business rule), you can use partial views.
In this example, my viewmodel has a property called "UseAlternateView":
public class TestModel : PageModel
{
public bool UseAlternateView { get; set; }
public void OnGet()
{
// Here goes code that can set UseAlternateView=true in certain conditions
}
}
In my Razor View, I renderize a diferent partial view depending of the value of the UseAlternateView property:
#model MyProject.Pages.TestModel
#if (Model.UseAlternateView)
{
await Html.RenderPartialAsync("_View1", Model);
}
else
{
await Html.RenderPartialAsync("_View2", Model);
}
The partial views (files "_View1.cshtml" and "_View2.cshtml"), contain code like this:
#model MyProject.Pages.TestModel
<div>
Here goes page content, including forms with binding to Model properties
when necessary
</div>
Obs.: when using partial views like this, you cannot use #Region, so you may need to look for an anternative for inserting scripts and styles in the correct place on the master page.

HttpRequest.Form collection gets cleared after Managed HttpModule

I’m suffering this issue I can’t find an explanation for.
Have a website that handles ASP and ASPX requests.
All requests run through a custom managed module, named MyModule, let’s say for “logging purposes”.
This is the WebConfig:
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" />
</system.web>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="MyModule" type="MySample.MyModule" preCondition="managedHandler" />
</modules>
</system.webServer>
</configuration>
So, if a form is posted to /action.asp via AJAX, an html form, or whatever, on /action.asp I can see and print the data on the Request.Form collection.
This is /action.asp
<%#LANGUAGE="VBSCRIPT" CODEPAGE="65001"%>
<%
dim count
count = Request.Form.Count
Response.write("Result: " & count)
Response.End()
%>
But, if in my custom managed module I just “PEEK” at the form collection before it’s handled by the ASP page, the collection disappears, it’s no longer available to /action.asp
This is the MyModule:
namespace MySample
{
public class MyModule : IHttpModule
{
public MyModule()
{
}
public void Init(HttpApplication context)
{
context.BeginRequest += context_BeginRequest;
}
void context_BeginRequest(object sender, EventArgs e)
{
/*
* ALL REQUESTS PASS THROUGH THIS POINT BEFORE CONTINUING.
* COUNTING THE ITEMS ON THE FORM WILL CAUSE THE FORM-COLLECTION
* TO BE CLEARED WHEN IT'S HANDLED BY ASP.
*/
int count = HttpContext.Current.Request.Form.Count;
}
public void Dispose()
{
}
}
}
It’s extremely odd. If I “comment” the count line, the form collection is handled unmodified to the ASP page. I just have to peek at it to run it.
I want to find an explanation for this backed up with some documentation, not just a hunch.
I can’t set to false the runAllManagedModulesForAllRequests, this is not an option.
I debugged the request through different .NET method calls, and many things happen when you query the Form object on .NET HttpRequest object,
// Form collection
/// Gets a collection of Form variables.
public NameValueCollection Form {
get {
EnsureForm();
if (_flags[needToValidateForm]) {
_flags.Clear(needToValidateForm);
ValidateHttpValueCollection(_form, RequestValidationSource.Form);
}
return _form;
}
}
// Populates the Form property but does not hook up validation.
internal HttpValueCollection EnsureForm() {
if (_form == null) {
_form = new HttpValueCollection();
/// THE FOLLWING METHOD AS A LOT OF SUB-CALLS AS WELL
if (_wr != null)
FillInFormCollection();
_form.MakeReadOnly();
}
return _form;
}
Is what I am experiencing an expected behavior ? What’s the documentation or the reasoning to back up this behavior ?

Is it possible to extend the ASP.NET 4.0 RequestValidator?

I am running into the problem with requestValidationMode="4.0" where if you submit html tags in a form the request will be marked as invalid and the app will throw A potentially dangerous Request.Form value was detected from the client.
The two most popular solutions are to use requestValidationMode="2.0" combined with validateRequest='false' on either a global level or keeping global as 4.0 but making a subdirectory that is listed as 2.0 in its web.config and putting all the pages that you don't want validated there.
What I would really like is to keep 4.0 but add a little logic to the 4.0 RequestValidator class to prevent it from throwing an error if it's just HTML in a form.
I'm stupid. It's right in the documentation.
namespace WebApplication4
{
public class CustomRequestValidator : RequestValidator
{
protected override bool IsValidRequestString(
HttpContext context, string value,
RequestValidationSource requestValidationSource, string collectionKey,
out int validationFailureIndex)
{
return base.IsValidRequestString(context, value, requestValidationSource, collectionKey, out validationFailureIndex);
//validationFailureIndex = -1;
//return true;
}
}
}
<system.web>
<httpRuntime targetFramework="4.5" requestValidationType="WebApplication4.CustomRequestValidator "/>
...
</system.web>

Overridden GetVaryByCustomString method being called only on first request to a page

I have the following question regarding outputcache work in either ASP.Net or Composite C1 CMS (don't know where's the problem):
I need to vary cache by cookie named "City". In Global.asax I've overridden the GetVaryByCustomString method.
public override string GetVaryByCustomString(HttpContext context, string custom)
{
var result = ApplicationLevelEventHandlers.GetVaryByCustomString(context, custom);
if (result == null) {
return base.GetVaryByCustomString(context, custom);
}
HttpCookie cookie = context.Request.Cookies["City"];
string additionalVary = "";
if (cookie != null)
additionalVary = cookie.Value;
else
additionalVary = "Москва";
return String.Concat(result, additionalVary);
}
And the problem is: the breakpoint of my overridden GetVaryByCustomString method is being hit only on the first request to a page, but isn't being hit on next requests until the cache actually expires (60 seconds in my case).
While the cookie might have been changed on the client side during that 60 seconds - the page is simply taken from the cache.
Where am I wrong?
Thanks in advance.
UPDATE:
I was finally able to make outputcache vary by cookie by the following modifications in the CacheProfile settings:
<outputCacheProfiles>
<add name="C1Page" duration="60" varyByCustom="C1Page" varyByParam="*" varyByHeader="Cookie" location="Server" />
</outputCacheProfiles>
In this case the method GetVaryByCustomString is being hit on each request, but there's no need in it: these settings make the cache vary by every cookie might be set on the website. Of course it is not a desired behavior - that's why I'm continuing the investigation.
What is even more funny - these 2 parameters (varyByHeader="Cookie" and location="Server") work only together, disabling one of them make the things look exactly as before - outputcache not varying.
Try to put a break point to Application_BeginRequest, it could be that browser isn't making a request but rather showing a cached page.

asp.net 4.0 web forms routing - default/wildcard route

I there a simple way when using ASP.NET 4.0 routing with Web Forms to produce a route that will act as some kind of wildcard?
It seems to me that within WebForms, you have to specify a route for every page - I am looking for some kind of generic route that can be used where nothing specific is required, perhaps mapping directly from path to path so...
http://somedomain.com/folder1/folder2/page would possibly map to folder1/folder2/page.aspx
Any suggestions?
Thanks
You can match all remaining routes like this:
routes.MapPageRoute("defaultRoute", "{*value}", "~/Missing.aspx");
In this case, we know all routes, and want to send anything else to a "missing"/404 page. Just be sure to put this as the last route, since it is a wildcard and will catch everything.
Alternatively you could register a route the same way, but internally does mapping to a page, like this:
routes.Add(new Route("{*value}", new DefaultRouteHandler()));
That handler class would do your wildcard mapping, something like this:
public class DefaultRouteHandler : IRouteHandler
{
public IHttpHandler GetHttpHandler(RequestContext requestContext)
{
//Url mapping however you want here:
var pageUrl = requestContext.RouteData.Route.Url + ".aspx";
var page = BuildManager.CreateInstanceFromVirtualPath(pageUrl, typeof(Page))
as IHttpHandler;
if (page != null)
{
//Set the <form>'s postback url to the route
var webForm = page as Page;
if (webForm != null)
webForm.Load += delegate { webForm.Form.Action =
requestContext.HttpContext.Request.RawUrl; };
}
return page;
}
}
This is broken a bit in odd places to prevent horizontal scrolling, but you get the overall point. Again, make sure this is the last route, otherwise it'll handle all your routes.
Additionally - Keep in mind that you need to add an exception for the .axd files in your Global.asax file if there are validation controls in your web app:
http://basgun.wordpress.com/2010/10/25/getting-syntax-error-in-asp-net-routing-due-to-webresource-axd/
Otherwise, you will keep getting a syntax error because the routing picks up the .axd files and not properly loads the JavaScript files needed for the validation controls.

Resources