Using: Visual Studio 2010 with ASP.net 4.0
I have a website which uses URL rewriting and I want to keep the rewritten URL on Postback. I've read a lot of the topics on this subject and I still haven't been able to figure out if this is possible.
For example:
http://localhost/ActualPage.aspx?PageID=4
Is rewritten as:
http://localhost/member/forum.aspx
The page contains a number of controls which use a Postback (for example a Telerik RadGrid with sorting and paging). Normally when the postback takes place the browser is redirected to the unrewritten url - the address bar shows /ActualPage.aspx?PageID=4 etc. In this scenario everything works correctly.
However I want to retain the rewritten URL after the postback, so I have coded to change the Form.Action property to be the rewritten URL like so:
Page.Form.Action = "/member/forum.aspx"
Now the page correctly retains the URL in the address bar but throws a "Validation of viewstate MAC failed" error when the postback occurs - which I would expect it too as the viewstate originated from a different URL.
Strangely this problem occurs even when enableViewStateMac is set to false (either in the page or in the web.config) - but I don't want to disable this anyway.
Effectively I think what I need to do is tell the page / viewstate mac authorisation that is it ok to accept input from this alternative URL but I can't find anyway of doing this. I've tried different URL rewrite system to see if that makes a difference, and i've tried added a generated machineKey - neither of which has made any difference. Is there any way of doing this?
In short I want:
Rewritten page with postback going to the rewritten URL
ViewStateMac enabled
No viewstate validation errors
I remember in earlier versions of .NET using a .browser file with FormRewriterControlAdapter but this doesn't seem to make any difference in .NET 4 (I don't remember if it successfully retained the URL anyway).
I have found a solution - it turns out the problem was actually unrelated and masking itself as a ViewStateMac issue.
Previously I had been redirecting all the URLs to one page, doing a database lookup and then using Server.Transfer() to deliver the correct page to the browser. The real problem was being caused by using Server.Transfer() - which it seems is recognised by Microsoft to be an issue when working with the viewstate.
I have made adjustments so IIS performs the database lookup, the entire rewrite and therefore Server.Transfer() is not used - and the original problem I had has been resolved.
Related
I am encountering a strange issue which is only affecting several users from an over 7000 user-base. Having searched the web for several hours to no avail, I'm hoping someone here can help!
I have an ASP.NET 2.0 website and when certain users try to access the home page (Default.aspx) they receive a white screen with no content loaded. This issue is occurring both in production environment and if I run the solution against a copy of production data. So I am able to replicate the exact same issue when I pseudo the problematic users.
When debugging the application in VS2005 and set a breakpoint in the code behind in the Default.aspx, the breakpoints are fired/hit so I know the request is working. The problem seems to be once the server has finished serving the request, the response back to the client/browser is empty.
Here's another strange thing I've noticed. If I alter the HTML in Default.aspx by adding a new white line or whitespace, the page will load fine for the same set of users. I thought I had resolved the issue with this fix but unfortunately the white screen issue just manifests itself once again.
Within Default.aspx, there's some AJAX requests using jQuery .load function but this can't be the issue because this functionality exists for every user of the site. The only variable is the amount of content returned within this request can vary depending on the user. But why would it resolve itself when I put a whitespace or whiteline in the page and then manifest itself hours later?
Another thing to note is it's only Default.aspx that is encountering this issue. If I browse to another page by typing in a page in the address bar, the page is served OK.
Hope someone can point me in the right direction on how I can debug or even resolve the issue.
It sounds like your ajax is the cause but without seeing some code, it's difficult to know why.
It could be a timeout, or an error that is preventing the ajax from completing it's function.
You need to use a tool like Charles or Fiddler to debug what is happening whilst the page loads whilst logged in as these users. In a nutshell, a tool like Charles will display all the detail surrounding requests made and responses served to the browser, including any failed responses.
I think it has to do with http headers, caching or encoding. But I cannot tell more without code.
Is output caching enabled for this page?
Can you give us the raw http headers for both the request and response?
If a white screen appears, will it be fixed by pressing ctrl+f5?
I have a legacy ASP.NET application. It was converted from NET 2 to net 4.
It uses state server session.
At some point, the app opens a new page (in a new browser tab: link target = "_blank")
But after returning to calling page (tab), I discovered the session is reset, so current user is no longer used and app redirects to login page. Actually, SessionID remains unchanged, but IsSessionNew is set to true, and session has no variables set in it.
The app doesn't use Session.Abort or Session.Clear.
Even if I change session to InProc, and change the target for the links to _top, or _self, or remove entirely, the same thing happens - session got reset.
This is session setting in web.config (alternatively I used StateServer, but with same result)
<sessionState timeout="432000" cookieless="UseCookies" mode="InProc"/>
Any idea what can cause this?
Thank you.
I finally fixed the problem.
However, I didn't found the actual cause, but I found the module which caused the issue.
It was a aspx page which did 1001 things (it's basic functionality plus another approximatively 80 other things based on ajax calls (!!!). I didn't made that page !!!
But the part that caused the problem was a functionality that served an image file.
So I rewrite that part as an ASHX handler, and then the code worked ok - the session remained open.
I'm using the old 404-rewrite method on a certain site that is tied to IIS6 *.
So if I enter
http://example.com/non-existent/path
it calls my error page like so
http://example.com/catch.aspx?404;http://example.com/non-existent/path
Great.
Except if I call the page with a fragment, like
http://example.com/non-existent/path#with-fragment
I get the same result as above. I can't find the fragment anywhere:
Request.Url
Request.Url.OriginalString
Request.UrlReferrer
Request.RawUrl
headers, server variables, etc
This has come up because I want to resolve paths created by AJAX to their server-side versions.
Is there any way for me to retrieve the original path from my handler?
Thanks.
(*) Please don't suggest I change platform. Obviously I would if I could.
No, there isn't.
The portion of URL after # is never passed to the server per HTTP spec. Has nothing to do with platform.
To work with info after # in javascript you should look at Javascript History plugins/functionality. jQuery has history plugin, asp.net ajax and mvc ajax (partial views et al) have that. Mind you, it's not a very easy thing to implement, you have to get into undo/redo mindset.
It probably won't work if you are trying to handle 404's on the server - server doesn't know that there was something after #. Not sure what you want to do though, 404 handling, or "resolve paths created by AJAX"? What exactly is the goal?
I've got a page with a large viewstate that appears to be tuncated during postbacks on one of our client's server. We will minimize this in the next release.
I'm trying the maxPageStateFieldLength page attribute in web.config, but it looks like this attribute is ignored. Viewstate size is larger than the value in bytes placed in this attribute, so the viewstate should be chunked in multiple input fields, but the page is generated with a single input field.
server is 2003/IIS 6, using compression.
Naming the attribute with an uppercase M triggers an error, so i know that it is recognized (with lowercase m) but asp.net does no chunking.
It is working with the same application under VS 2005 using internal web server on my dev machine.
Any idea what might cause this attribute to be ignored?
This link explain the behavior described in my last comment. Precompilation to a non updatable web site hardcode some page parameter values in the assembly, like theme, and i just found out, viewstate chunking
I have an ASP.Net 3.0 SP1 app that uses Form Authentication.
While testing, I noticed that if I viewed a page that another user was viewing, the other users name would be displayed in the control on my master page. The Context.User.Identity is also for the other user.
If I switch to different page that no one else is viewing the Context.User.Identity is correct.
I stumped and would appreciate suggestions.
Thanks in advance.
Chris
Maybe because output caching is enabled for the page: if the page is cached server-side with VaryByParam=none, all users will get the same copy from the cache.
I can only think of two things that can cause this:
You're storing user-specific data in a place shared between requests (e.g. in a static(C#)/shared(VB) variable, in the ASP.NET Cache, in the Application object, ...)
You have output caching enabled.
Check for:
OutputCache directives in your aspx and ascx files,
system.web/caching element in your web.config file(s),
Calls to the HttpCacheability.SetCacheability method.
If you can't find the problem:
Try creating a simplified version of your application until you get the simplest possible version that still reproduces the undesirable behaviour.
During this process of simplification you'll likely discover the problem for yourself. If not, post some code from the simplified version.
Make sure you are not using a link that comes with the authentication ticket when using a cookieless browser.
Also make sure to review any other that might be sharing the data among requests. Just like DOK said, but remember Application isn't the only way you could be doing that.
It looks like the issue was caused because I setting targetframe="_self" or Target="_self". I removed all these and everything seem to be working fine.
One other note: If I were to refresh the page it would also display the page with the correct user.