Posts Tagged ‘ASP.Net’

ASP.Net Cookieless Session and Absolute URLs

Monday, February 18th, 2013

For one of our ASP.Net websites, we have been using the Cookies mode to “AutoDetect” (by adding cookieless=”AutoDetect” in sessionState tag in web.config). This has worked well for years in serving the website correctly to users with all types of securities (even who don’t allow the web cookies).

When the cookies are disabled by the user security policies, then ASP.Net auto detect this and adds the session info in the URL of the each request, something like::
~/(X(1)S(cp53yq30mtagv555unhr0t45))/system/index.aspx

The cryptic path “(X(1)S(cp53yq30mtagv555unhr0t45))” in the URL is actually used to indicate the session ID. ASP.Net auto manage the addition and removal of this session info, and in the ASP.Net codebehind, you don’t need to worry about this. Even you don’t get this URL with session info with Request.URL or any other property.

The only limitation is that this breaks when you try to redirect from ASP.Net to an absolute URL e.g. “/system/index.asp”. We normally don’t use any absolute URL in our application, but there are few places where the absolute path is used (mostly to handle protocol changes), and we discovered that it was causing mysterious automatic log-out for some users (which were not allowing cookies).

The fix, fortunately, was very simple. The ASP.Net naively provides a method which add the current session ID to the URL if using the Cookieless mode. The method is HttpResponse.ApplyAppPathModifier and you can apply this by simply calling and passing required absolute URL:

1

string redirectUrl = Response.ApplyAppPathModifier("/system/index.aspx")

The beauty of this method is that it auto detects the session mode and only appends session info, if required. If want to know more about Cookieless session in general, I would suggestion this MSDN article:
http://msdn.microsoft.com/en-us/library/aa479314.aspx

Tags: , ,
Posted in ASP.Net | No Comments »

ASP.Net SecurityProtocol (for SSL Version Control)

Thursday, January 3rd, 2013

Recently, when working on an integration API written in ASP.Net which communicates with a web-services developed using PHP, the tech support requested to force all the secure communication (over HTTPS) to use only the SSL v3 version.

This can be controlled in PHP CURL via single line of code as shown blow:

1

curl_setopt($curl, CURLOPT_SSLVERSION,3);

For more details on this, please check curl-setopt. Doing this in the ASP.Net was a single line of code as well, but finding it was not that easy. Here is the code which did the trick for me:

1
2
3
4
5
6
7
8
9
10
11
12
13

try
{
	// Take back-up of current protocl and force use of only SSL3
	SecurityProtocolType activeProtocol = ServicePointManager.SecurityProtocol;
	ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;
 
	// The ASP.Net communciation (using HttpWebRequest) goes here
}
catch {}
finally {
	// Restore the orignal protocol
	ServicePointManager.SecurityProtocol = activeProtocol;
}

I hope this helps.

Tags: , , ,
Posted in ASP.Net, C# | No Comments »

ASP.Net Error CVT1108: Cannot open C:\Windows\TEMP for writing

Tuesday, December 18th, 2012

When I restarted my Windows 7 machine today after a few days (I usual put this to hibernate mode), I got a weird error when starting the ASP.Net web application. The error was:

Compiler Error Message: CVT1108: cannot open C:\Windows\TEMP\RESA33F.tmp for writing

This was a bit weird, because it was working fine before the restart. I tried clearing all the files in the above TEMP folder, but the error still persistent.

After trying various solutions, I was finally able to solve this by simply re-applying the full permissions to “CREATOR OWNER” group in the Security page of folder properties dialog.

I still wonder how these properties got corrupt, and it’s still a mystery, but the good thing is that system is finally back to working state.

Tags: , , ,
Posted in ASP.Net, Windows | No Comments »

ASP.Net designer.cs Not Auto Updating

Sunday, August 26th, 2012

If you use the ASP.Net Web Application project, then there are chances that you have to face a problem, where the designer.cs for the wep page stop auto upadating as you add the new controls to the page. When this happens, it’s really frustrating as you don’t get the error on why it’s not being auto updated. Plus I can’t seem to find some intutive for force regenerate this too.

Today was one such day. I ended up wasting around an hour on the issue where the designer.cs was not being updating for new controls for the Site.Master page. Usually when this happens, the trick which works for me is that I manually add a new ASP.Net server control, switch to the designer.cs and save it. It works almost 99% of the time.

However today was a bad day (that 1% time), where the above solution didn’t worked. Tired up, I started reviewing all the ASP.Net server tags (have to remove couple of those too), and finally found the issue. The problem was that one of the ASP.Net custom control tag was mis-spelled. Once I fixed that typo, the designer.cs started updating correctly. But what was frustrating that there was no error for this, instead the designer.cs just stopped auto updating after that control.

During all this research (and frustrating) process, I found the following nice tip to force regnerate the designer.cs file:

1) Right-Click the designer.cs file and then select ‘Delete’
2) Once the designer file is created, select on the main .aspx, .ascx or .master page, right-click and select ‘Convert to Web Application’.
3) See the magic.

If there was an error due to which the designer.cs file was not being auto updated, you should see the detail of that error too. Yeah!

Tags: , ,
Posted in ASP.Net | No Comments »

One possible reason for “The state information is invalid for this page…” exception

Thursday, November 8th, 2007

One of our client was randomly having the ASP.net “The state information is invalid for this page and might be corrupt” error on the pages. The weird thing was that it seems to be random. After some testing, we finally found a pattern and ultimately were able find the root cause of the bug. Though there are various reason for this issues (including some reported ASP.net bugs), but one we found doesn’t seems to be documented anywhere. This only happens during in Microsoft AJAX callback and if you have ASP.net ViewState chunking feature enabled.

Please note that sending ViewState in chunks is a new feature in ASP.net 2.0 and let web administrator control how much information is stored in a single view-state variables. This helps keep site running on some of the old proxy and web-browsers (which have a maximum limit for the hidden field length).

After I found a pattern of the problem, we run the HTTP packet analyzer to view the
AJAX response and found something interesting. It seems that there is a problem with the code handling the ViewState chunked fields on the client-side. It’s not the case that ASP.net AJAX programmers forgot to handle this (come on, they are Microsoft’s programmers, how can they miss so obvious thing), but rather you need a little more complex cycle to break this working. I found that as long as the AJAX call returns the larger or same size of ViewState hidden fields it keep working, the problem arises when the page send the smaller number of ViewState than the previous call (which is quite possible specially on last page of the ASP.net Repeater or Grid results).

 

Here is how I found this. In the client web.config, the maximum length of the ViewState is set to 8K using following attribute maxPageStateFieldLength=“8192“. Now I went to the application search page, and here is a snapshot of the initial headers.

<div>
<input type=”hidden” name=”__EVENTTARGET” id=”__EVENTTARGET” value=”" /><input type=”hidden” name=”__EVENTARGUMENT” id=”__EVENTARGUMENT” value=”" /><input type=”hidden” name=”__VIEWSTATE” id=”__VIEWSTATE” value=”/wEPDwUKMjEwNzE…S4=” /></div>

As you can see, there is just a single view-state field on the page-load. When I performed a search on that page, page generated an
AJAX call to get the results from the server. Server found the first page of result set (containing 100 items) and this increased the response ViewState size to around 12 KB. Here is how the AJAX response looked like (I captured this using a packet viewer tool):

1|hiddenField|__VIEWSTATEFIELDCOUNT|2|8192|hiddenField|__VIEWSTATE|/wEPDwUKMjEwNzE1…9u|1444|hiddenField|__VIEWSTATE1|LmN..FQ==|

As you can see that this time there were two ViewState fields, but the page rendered correctly and I was able to make another
AJAX calls. So clearly the AJAX handles this growing field scenario very nicely. Now when I navigation to the next page (again using AJAX call), that page has less items (as it was last page) and thus ViewState size was decreased. Here is what was returned as ViewState:

7060|hiddenField|__VIEWSTATE|/wEPD…F8Q==|

As you can see that though the size of view-state is decreased correctly to just one hidden field (enough to have the data), but ASP.net didn’t returned the ViewState maximum size info as the first
AJAX call has. So it seems here is a some problem in the AJAX client implementation and it leaves the ViewState value of existing higher ViewState fields. So when you submit that page or make any other calls, browse sends all the ViewState (including the one related to previous AJAX
call) and thus it invalidate the state and ASP.net throw the exception. Looking at the post data confirmed my assumption. Here is what was being sent to the ASP.net server:

__VIEWSTATE=/wEP…F8Q==

__VIEWSTATEFIELDCOUNT=2

__VIEWSTATE1=LmNv…FQ==

 

As you can that view-state is still communicating that it has 2 fields hidden fields, while only the first field has a valid and complete data. Of course, the ASP.net validation routine will treat this as a view-state corruption and will throw the error.

 

In short, though I can dig deep into AJAX client library to fix the issue, but I will leave this off to Microsoft programmers (they get big bucks to do this job). For now I have just disabled the ViewState size limit in the client website and things seems back to normal.

Tags: , , ,
Posted in ASP.Net | 14 Comments »