I've recently been hacking with webforms seeing if it's possible to use one of my (routing) projects with it. So far, it's been nothing but trouble, but I'm almost to the point that it "works"
I made a page "Test.aspx". At Global.asax, I made it so that it's served at /test instead of /Test.aspx. This works completely. It descends from a custom page class of mine. The custom class finds HtmlForms in the page and rewrites their Action attribute with the proper value: /test.
Now I hit the great brick wall titled Viewstate and ASP.Net events. I added a button to Test.aspx with an OnClick handler. I can click the button, and the page will postback and such, but the OnClick event will not occur. I'm not understanding how a simple URL change can break viewstate like this, as I was not under the impression that Viewstate would track such a thing. Also, IsPostback will be false, even though HttpMethod==true. This is not making any sense to me.
Also, I've disabled EventValidation because I figured that'd be trouble, but this problem persists.
How can I make viewstate and postbacks work as usual when rewriting URLs?
(Note, my form of URL rewriting does all rewriting internally, there is never a HTTP redirect sent to the user)
You might need to tell the HttpContext that the URL is being rewritten as well.
Try doing something like this:
HttpContext.Current.RewritePath("/test");
The IsPostBack is used for check whether the request is from the control of the page itself.
And the HttpMethod is used for check the request type.
Related
I thought you couldn't change the QueryString on the server without a redirect.
But this code works* for me:
Request.QueryString edit
I'm so amazed.
So here are my questions regarding this:
Why is Request.QueryString readonly?
Why does this code/hack work*?
How safe is it, if you change to readonly as soon as you are done editing, both regarding bad errors or unexpected behaviour, and regarding maintaining and understanding the code?
Where in the event cycle would it make most sense to do this crazy edit if you are only using PageLoad and OnPageRender?
*More details:
I have a page with items that are grouped into tabs. Each tab is an asp:LinkButton
I want to be able to link directly to a specific tab. I do that with a QueryString parameter 'tab=tabName'. It works. But when I then click a new tab, the querystring is still in the Url, and thus the tab specified in the Querystring gets activated and not the one I clicked.
By using Request.QueryString edit this does not happen. Then my solution 'works'.
Thanks in advance.
Well the QueryString property is readonly because it cannot be changed on a single request. Obviously the browser sends only one request with only one string so only one collection is created. The hack uses reflection (i.e. manipulates the code and the memory) to change stuff that you cannot change normally. This hack breaks the encapsulation and the design of the QueryString property. You should not use it. It makes no sense from design standpoint. Your query DOES NOT change so why change the object that represents it? Only the browser can send new query string so you are basically lying to your own code about what the browser sent.
If you want the tabs to use the URL just use Hyperlinks instead of LinkButton.
From what I remember reading, this is a security standard that all browsers adhere to. It's main purpose is to stop phishing attacks, where someone could have the website www.MyLameWarcraftPhishingSite.com" and when someone hits the page, rewrite the url to look like www.blizzard.com. The only way to get to that url is to actually redirect to it.
mmm, last post was in Feb 11 - hope its ok to post in this.
I have a page where I set the PostBackUrl property on a login button. I am using the IIS7 Url Rewriting Module. I am also rewriting the Page.Form.Action attribute to match the rewritten url, so that postbacks work properly. When I have the PostBackUrl property set, the page adds a "__PREVIOUSPAGE" hidden input. The problem is that ALL postbacks are now broken, such that the request is seen as a new request, and Page.IsPostback == false. Removing the line of code that sets PostBackUrl fixes all my postback issues.
I don't think I can rewrite the encrypted __PREVIOUSPAGE value to match the current rewritten url, but I suspect that is the issue. Has anyone else encountered and solved this problem?
ASP.NET webforms and url rewriting have never played particularly well. You might want to look at routing, which will work loads better . . .
I only need to parse URL Request.Querystrings on GET, not on postback, right?
if(!IsPostBack)
{
Viewstate["magic_number"] = Parse(Request.Query);
}
The user can't be expected to modify the URL in the Request for subsequent postbacks, or can they?
Motivation for question-- I don't control the javascript snippet that does the postback, so it's something of blackbox to me.
The URL is not expected to change. But remember that each postback is a new instance of your page class. So if you didn't save the results somewhere on the first view you need to be prepared to do it again on the next one, and so on. In this case you saved it to ViewState, and so that should be fine.
However, I suspect you wouldn't be asking the question unless you had observed behavior that led you to suspect otherwise. So let's consider for a moment what things could cause this to break:
It is possible to modify ViewState at the client where you saved your results (though not trivial and definitely not recommended).
You can fake a postback before the initial page view.
You can use javascript to alter the posted url.
However, for all these things you would certainly know if you have written anything to do that.
Your assumption is correct, the URL is not expected to be modified in subequent post backs and you need to parse the query string only on the GET, which happens the first time the page is loaded.
The URL does not normally change for a postback.
It's of course possible to use a tool like FireBug to edit the URL in the form tag before the postback, but then you probably don't want the value that the user injected anyway, but the original value.
As others have pointed out, The URL is not expected to change. Of course if we lived in a perfect world you would never get email spam and noone would ever attempt to do anything malicious to your website.
In the real world you should expect that malicious people will attempt to hijack your website and need to be concerned with things like injection attacks
You should never make any assumptions that the data received on a postback is valid.
Doing a refresh after certain action in asp.net seems to make them happen again even when that action doesn't make sense (think double delete). The web way to deal with this situation is to redirect after a post to get a clean version of the page that can be refreshed without reposting an action to the webserver. How can I do this with ASP.NET
I have a feeling there is a deeper problem I'm not getting but here goes. In your postback event:
// the post handling logic, e.g. the click event code
Response.Redirect(Request.RawUrl);
Use Server.Transfer method.
The Server.Transfer method has a second parameter—"preserveForm". If you set this to True, using a statement such as Server.Transfer("WebForm2.aspx", True), the existing query string and any form variables will still be available to the page you are transferring to.
http://www.developer.com/net/asp/article.php/3299641
I'm hoping someone has seen this before because I can't for the life of me find the problem.
I'm trying to do the old "fix the back button" thing in an application and I think i have a pretty decent approach, the problem is that it relies on the application not calling page_load when you hit back and instead loading the cached version of the page.
On about 60% of my pages that's exactly what happens. It loads the cached version and all is well. On the other 40% when i hit the back button page_load calls, forcing a refresh. For reference the call to page_load is NOT in a postback.
Even stranger is that this only occurs in IE (6 & 7). In firefox page_load never gets called.
I am using ASP.NET Ajax framework on both types of pages. Anyone seen anything like this before?
--Update--
After investigating a bit more I'm finding out that when i use the search to navigate from one page to another the application behaves differently for different pages. On the broken pages the page_load gets called twice, the search gets called twice and in fiddler that turns into 2 different redirect postbacks the second of which has no-cache set.
On the working page page_load and search only happen once and it immediately redirects.
That second Response.Redirect is causing the issue. Still not sure why that's happening though.
Check what the server is returning for the cache-control http header, then try setting Response.Cache.SetCacheability()/ use the output cache page directive on the pages and see if the server is saying that the pages should be cached.
if you are using ASP.NET AJAX why not using the History server control object?
replacing History, the back button will go to the link you want.
try this