Develop Reference

ASP.NET 4.0 MAC validation failure

To begin, I should mention that I'm quite new to C# and ASP.NET 4.0. The solution to this problem may be elementary so don't hesitate to ask fundamental questions.
I've inherited an ASP.NET 4.0 application that failed our automated security test because of <page enableViewStateMac="false"> (not my fault). Of course, I turned it on. At that point a very specific pattern of behavior emerged:
1) I can navigate to the application landing page
2) attempting to click on any link leaving the landing page results in a "Validation of viewstate MAC failed..." error.
2a) the exception to this is that clicking on the link that takes me to the landing page (the page I'm already on) works just fine
I should mention that navigation to other ASPs occurs by way of Response.Redirect(...). I can successfully navigate to a page if I enter the url directly into the nav bar (http://dummyhost.com:12345/Enroll.aspx as opposed to http://dummyhost.com:12345/LandingPage.aspx and then clicking on enroll).
In the Page_Init() method of the master page, I'm setting:
Page.ViewStateUserKey = Session.SessionID;
If I comment out this line, I can turn on MAC and the application is perfectly happy. Can anyone illuminate what's going on?

The most likely cause is that some landing-page-specific data is being submitted to the server and persisting through the call to Response.Redirect, so the enrollment page tries to read the landing-page-specific data and fails the request since the data cannot be interpreted correctly.
Instead of using Response.Redirect, consider using ... directly in your markup when you want to generate a simple link. This will cause the browser to make a vanilla HTTP GET request to the specified resource, free of any current-page-specific date.

Site using code behind files from the wrong directory?

What settings in ASP.NET determine where (as in which directorie(s)) a website will look for its code-behind files?
I have two versions of an asp.net c# website, Live and Dev.
Live site: www.example.com with the pages and code in c:\dev\websites\examplecom_new
Dev site: d3.example.com with the pages and code in c:\dev\websites\examplecom-d2
There are historic reasons why the live site's directory ends in _new and why the dev site has d3 as its hostname and -d2 on its directory name, but they work and until now we've had no issues, developing things on d3 for subsequent release to live.
I recently refreshed the dev site to be an exact copy of the live one (I usually do this before starting a new round of work), and started on some development work. However, when I tried to run the code via the website, even though the browser was showing the Dev URL, d3.example.com, the error message referenced a code file from the live site's web directory, c:\dev\examplecom_new, not the development version c:\dev\examplecom-d2.
I've gone through the code in detail to ensure there are no hard-coded references to either the www site or the path to the live site directory, and as far as I can tell there are none. The code files in all cases are referred to in the .aspx files as local links, for example:
<%# Page Language="C#" MasterPageFile="~/ExampleCom.master" AutoEventWireup="true"
CodeFile="Checkout.aspx.cs" Inherits="Checkout" Title="Untitled Page" %>
Yeah, I know "Untitled Page" isn't the most useful title in the world. :)
I've gone through web.config, had a look in app_code\general.cs, and checked all the tabs on the Properties element in IIS, but I can't find anything that could be telling the site to use the .cs files from the live dir instead of the dev one.
I tried restoring the previous (pre-refresh) version of the Dev site (I always back them up before replacing, just in case), just in case there was a config change I wasn't aware of, but the old version exhibits exactly the same problem, the Checkout page calls code from live, not dev, even though its URL is showing the dev verson in the browser.
Needless to say this is something of a showstopper, the error that's happening appears to be due to a session mis-match between live and dev, but I have no idea why the dev site is calling code from the live site instead of code in its own directory. Any pointers to what might be wrong would be appreciated. I've tried both Googling for "asp.net code behind files called from wrong directory" and related searches, and searching Stack Overflow for the same types of thing, but not seen anything related. We're not using pre-compiled binaries, just standard .aspx pages and .aspx.cs C# code files.
At first I'd assumed there must have been a hardcoded redirect kicking things over from dev to live, however I can see no trace of one and the browser address bar still shows d3.example.com/Checkout.aspx when I'd have expected a redirect to live to change it to the www version.
The webserver is IIS 6 and we're running ASP 2.

Run "iisreset" command from command line and then clear temporary folder. All applications will be recompiled after that.

.NET Cookies still working even tho' I have disabled cookies in browser. How?

I am trying to disable cookies in my browser, and check that they are disabled in my .Net web app.
One on page I am storing a cookie like this:
HttpResponse response = HttpContext.Current.Response;
response.Cookies[cookieKey].Value = cookieValue.ToString();
On another page, I am retrieving the cookie like this:
cookieValue = request.Cookies[cookieKey].Value;
I am trying to disable cookies in my browser to make the above code fail but I can't seem to do that. I am using Internet Explorer 7 and 8. (I am working with these 2 browsers because IE7 is my company's current standard and IE8 is the future company standard).
In both of these browsers, I went to Internet Options > Privacy > Advanced, and checked override cookie handling, and blocked both 1st and 3rd party cookies (also deleted any existing cookies/history/temp files).
After doing that, I would expect the above code to not work, but it still works. I can still set and retrieve values from the cookie. Any idea why? I thought maybe the cookies aren't actually getting disabled, but if I go to hotmail.com, it gives me an error message saying "Your browser must allow cookies before you can use Windows Live ID." so I don't know.
Why do cookies still work when visiting my ASP.Net site?
Updated 5/14/2012:
It appears that the cookie settings in the privacy tab are ignored on local intranet sites (I don't know if that is normal or not) so this was giving me problems. I did however figure out a different way to disable cookies (which I needed for testing purposes), even for intranet sites. In IE8, I went to Tools > Developer Tools > Cache > Disable Cookies. This worked as expected and i could complete my testing. However I still have not found a solution for IE7.

Are you running the website locally?
I had a similar question I asked on SuperUser.
From what I can tell, Sparky was correct. localhost / 127.0.0.1 will always accept cookies regardless of your settings.

Different Behaviour of pdfConverter (ephtmltopdf) on 2 Different production Servers

I am using an ephtmltopdf dll to convert an .aspx page to a pdf.The pdf Converter successfully converted a published page on a production server which uses Windows 2008 server and IE 8 into a pdf.But when i published the same page on another production server which uses Windows 2003 server,it showed an error
Could not generate the PDF document. Could not render the url. Could
not get image from url.Navigation timeout..
I tried loading the page url which i am trying to convert to pdf in a web browser and surprisingly it loaded perfectly.First i thought may be some issue with my .aspx html code and i tested by publishing only the design of the .aspx page.And it was successfully converted.So i thought may be some issue with the c# code.So i checked my code log and surprisingly nothing seems wrong with the c# code.All c# code executed successfully.
After i bit of googling some suggested an increase in pdfconverter.Navigation timeout....so increased that too, but still getting the same error.

ephtmltopdf dll that i was using was some how corrupt i guess,since no matter what ever navigation timeout i was setting it was getting timed out after 1 min ...so i downloaded a new dll from their site .....and bingo it worked like a charm...

POSTing to a re-written URL on IIS 6 doesn't work

I am working on a site which is programmed in C# .net. It uses a CMS called ADX Studio (a decision which predates my time there) which provides a shonky form of URL Rewriting (as far as I can tell it works by assigning an aspx page as the default 404 handler in IIS).
I have an web form which lives at a rewritten URL. I edited it so that the html form's action points back to the rewritten URL:
var u = new Uri(Request.RawUrl.Split(new char[1] { ';' }).Last());
userAdminForm.Action = u.PathAndQuery;
(kind of ugly but works based on what Request.RawUrl is on these rewritten URLs).
The "pretty" URL is something like this:
http://www.site.com/admin/user/edit/
On my development box (Windows XP/ IIS 5) when I initially tried POSTing back to URLs like this I got a HTTP 405 error. I worked around this by adding a script mapping so Aspnet_isapi.dll handles all (*) requests. And everything works fine on my development machine.
I just pushed my changes to the live server (Windows Server 2003 R2 and IIS 6) and the post fails silently. The page refreshes but all of my logic (from within an IsPostBack path in the code) doesn't get hit. No errors are displayed, it just doesn't work.
If I remove my code setting the .Action of the form then the postback works but it is posting to the ugly URL corresponding to the physical location of the aspx file rather than my page.
Am I missing a simple way to make this work? I don't want to be switching URL rewriting method or anything as this is a large legacy site and is unfortunately pretty dependent on ADX Studio so I don't want to do anything that will break that.
[edited because somehow the code above lost its code highlighting]

The issue is that the page's <form> tag is referencing the "ugly" url as the action. You can resolve that by completely removing the action tag from the form. Browsers will, by default, postback to the same page, ie. the "pretty" url.
This article explains how to accomplish an "actionless" form (~ two thirds of the way down) http://msdn.microsoft.com/en-us/library/ms972974.aspx

It seems like the problem is the same as it was on IIS 5. I can get it to work by doing the following in the IIS Manager:
Right click on the relevant website and select "Properties"
Choose the "Home Directory" tab
Click "Configuration" down in the "Application settings"
Click "Insert" next to the "Wildcard application maps"
Browse to the location of aspnet_isapi.dll (in my case: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll )
Untick "Check that file exists"
Click "OK" back through the Russian doll of dialogs.
This is basically the same as the approach that I linked to in the question for IIS5. However, it's not optimal because IIS is running every request through asp (even static files). Which seems like it can only slow things down. I'd like to be able to specify that asp only needs invoking for HTTP POST requests at least.
The weird thing is that IIS5 gave a HTTP 405 error when POSTing to an extension without a registered ISAPI extension but IIS6 just fails silently. And the page is being run through IIS (I can debug with a breakpoint in the Page_Load function) but IsPostBack (and IsCrossPagePostBack) don't get correctly set. Could it be related to the view state? Is there any alternative to my solution described above?

I've come to what I think is an optimal solution for this problem. It turns out that ADXStudio CMS does use the default 404 rule to do some form of URL rewriting. This has a problem with http POST:
when IIS initially executes a custom
URL on a 404 error, it changes POST to
GET, even if the client does a POST
request.
(thanks to elite brains' blog post about setting up IIS6 and ASP.NET MVC).
Rather than creating my own HttpModule I decided instead to use Ionics Isapi Rewrite Filter to rewrite my URLs. I then set the 404 error handler in IIS to the default. And I created this IIRF.ini file to redirect all requests to the same format as the 404 handler produced:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /Default.aspx?404;http://%{HTTP_HOST}$1 [U,L]
And everything seems to work great. The advantage over my previous answer is that the rewrite code is low level and runs fast and the -f and -d switches mean that if a file actually exists it isn't re-written and so static files don't have the overhead of running through .net.