Showing posts with label posting. Show all posts
Showing posts with label posting. Show all posts

Saturday, March 24, 2012

Ability to fine-tune control over request validation

This is a subject that crosses multiple disciplines, but I'm posting it here (AJAX forum) because it was a partial postback (with Sys.Webforms.PageRequestManagerServerErrorException error) that stumped me.

I have a form that submits regular <input /> tags inside an UpdatePanel (not server controls). I was finishing debugging when I tried submitting something like "test<test>test" for a form value. The page would not do the partial update, and instead threw the error mentioned earlier in an alert box.

After messing around I figured out that it is ASP.NET guarding me against some malicious entry by hackers.

Changing ValidateRequest to false fixed the problem, but I hate to wipe something out completely, without knowing what I'm wiping out.

Is there some way to fine-tune control of what gets validated? Is there any way to know exactly what I've just disabled by setting ValidateRequest to false?

Thanks...

I'll give this one obnoxious bump, just to see if there's someone who may have some knowledge on this topic. If not, maybe it's just one of those areas where MS doesn't want to say what's going on under the covers. It would be nice to know what is going on with the validation, and what, if anything, can be controlled. For example, it would be great to subclass the functionality.


Hi,

It checks the following strings:

1. Is there a "&#" contained in the input string

2. Is there a "<[char]", "<!", "</" in the input string.


Great, thanks Raymond!

Wednesday, March 21, 2012

90 seconds delay for posting back to the server when user clicks the abortButton

Hi,

In my application, I have an UpdateProgress control with an abortButton. I hook the Onclick attribute of this button to a server-side method.

When the application does not contain a global.asax file, all is working perfectly: When the user click on the abortButton, it posts back immediately.

But, when the application contains a global.asax file, there is a delay of approximatively 90 seconds between the user's click of the abortButton and the execution of the method in the server-side.

Here's a little exemple how to reproduce the problem:

aspx page:

<%

@dotnet.itags.org.PageLanguage="C#"AutoEventWireup="true"CodeFile="Default.aspx.cs"Inherits="_Default" %>
<%@dotnet.itags.org.RegisterAssembly="Microsoft.Web.Atlas"Namespace="Microsoft.Web.UI"TagPrefix="cc1" %>
<!DOCTYPEhtmlPUBLIC"-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<htmlxmlns="http://www.w3.org/1999/xhtml"><headrunat="server">
<title>Untitled Page</title>
</head>
<body>
<formid="form1"runat="server">
<div>
<cc1:ScriptManagerID="ScriptManager1"runat="server"EnablePartialRendering="True">
</cc1:ScriptManager>
</div>
<cc1:UpdatePanelID="UpdatePanel1"runat="server">
<ContentTemplate>
<asp:ButtonID="Button1"runat="server"OnClick="Button1_Click"Text="Button"/>
<asp:LabelID="lblResultat"runat="server"Text="Label"></asp:Label>
</ContentTemplate>
</cc1:UpdatePanel>
<cc1:UpdateProgressID="UpdateProgress1"runat="server">
<ProgressTemplate>
Contacting server... <br/><br/>
<asp:buttonid="abortButton"runat="server"OnClick="abortButton_ServerClick"Text="Abort Request"/>
</ProgressTemplate>
</cc1:UpdateProgress>
</form>
</body>

Code behind:

using

System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using System.Threading;
using System.ComponentModel;
using System.Net;

public

partialclass_Default : System.Web.UI.Page
{
privateEventWaitHandle ewhWait =newEventWaitHandle(false,EventResetMode.ManualReset);

protectedvoid Page_Load(object sender,EventArgs e)
{
}

protectedvoid Button1_Click(object sender,EventArgs e)
{
Thread thread =newThread(newThreadStart(ThreadLong));
thread.Start();
ewhWait.WaitOne();
lblResultat.Text ="End of lengthy method";
}

publicvoid ThreadLong()
{
Thread.Sleep(100000);
ewhWait.Set();
}

protectedvoid abortButton_ServerClick(object sender,EventArgs e)
{
ewhWait.Set();
}
}

Global.asax

<%

@dotnet.itags.org.ApplicationLanguage="C#" %>
<scriptrunat="server">
void Application_Start(object sender,EventArgs e)
{
// Code that runs on application startup
}void Application_End(object sender,EventArgs e)
{
// Code that runs on application shutdown
}void Application_Error(object sender,EventArgs e)
{
// Code that runs when an unhandled error occurs
}void Session_Start(object sender,EventArgs e)
{
// Code that runs when a new session is started
}void Session_End(object sender,EventArgs e)
{
// Code that runs when a session ends.
// Note: The Session_End event is raised only when the sessionstate mode
// is set to InProc in the Web.config file. If session mode is set to StateServer
// or SQLServer, the event is not raised.
}
</script>

To Reproduce the problem:

1- put a breakpoint in theabortButton_ServerClick method
2- Execute the application and clickButton1
3- clickAbort Request
4- after 90 seconds, the application breaks.
5- Remove Global.asax from the solution
6- Execute the application and clickButton1
7- clickAbort Request
8- the application breaks immediately.

This delay appends also under different conditions; I explained the Global.asax case because it is the easiest to reproduce.

Is there someone knowing the reason of this behavior?

How can I force a postback of the abortButton ?

Thank you for any input .

Well it looks like you have gone to quite a bit of trouble just to get an abortButton cancel the current requests. I hate to tell you but there is a much easier way to abort requests. Atlas has a special button called abortButton (go figure). So basically the atlas framework looks for a button event with the id of abortButton. You don't have to create some custom method to cancel the request the atlas framework handles it, and it works great. Below is all you have to put into the UpdateProgress template and you will be set. At least now you have some really cool code to shutdown events :). By the way when you press the button it doesn't force a postback it just ends the request.

<

inputid="abortButton"type="button"runat="server"value="Stop"/
Have fun!

JoeWeb


Hi JoeWeb.

Thanks for your quick reply.

I am using the Atlas abortButton.
I don't think it's matter if it is a "input type=button" or a asp:button, both are translate by Atlas like this :

<button id="UpdateProgress1_abortButton">
<click>
<invokeMethod target="_PageRequestManager" method="abortPostBack" />
</click>
</button>

But just to be sure, I try this button

<input id="abortButton" runat="server" type="button" value="Stop" onclick="AbortRequest()" />

and in the javascript AbortRequest() I call the server via anICallbackEventHandler method.

Atlas is doing a great job cancelling the request on the client side. The problem is that it does not cancel it on the server-side, the methode is still running.
You can verify that by placing a breakpoint in a long request. Even if you cancel it, the breakpoint will eventually be hit.

In my application, if somebody cancel the request I have some cleanup to do. So, if somebody cancels with the abortButton, the server must be inform in some way.

I also notice that if you cancel a request and re-submit it immediately, Atlas waits 90 seconds before posting it to the server.


Don't know what to tell you then. The application we have using atlas handles about 15 million records in a database for tons and tons of customers and it handles requests just fine. Haven't had any problems with it taking longer to send a request right after aborting it. We serve alot of data back and forth and it handles the request no problem. Sorry, don't know what to tell you.

Good luck.

JoeWeb


I finally pin-pointed the problem with the Atlas abort button.

I was wrong when I said that there was no request to the server when the Abort Button is clicked.
I traced Global.asax and I found out that the BeginRequest event is triggered.

The problem is with the creation of the handler between the ResolveRequestCache event and the AcquireRequestState event; this operation takes almost two minutes to complete.

I don't know why it tooks so long. For other request than the Abort Button it's very fast.

Am I the only one to have this problem ?