ASP.net 4.0 Webforms Routing Postback Issue - asp.net

We are using asp.net 4.0 and routing with web forms to create friendly urls.
The routing is working fine except that the correct "action" value is not being assigned to the form element in the master page for any route that has multiple levels.
For example, the route ( customer/{customerid} ) when browsed to with .../customer/12345 only displays 12345 in the "action" attribute of the form. The issue with this is that it isn't complete and any postback fails and gives an error "The HTTP verb POST used to access path is not allowed" If I updates the action as "customer/12345" (using Firebug), the postback works fine.
It even errors when using static routes like customer/customer, it only puts "customer" and not "customer/customer" as the action value of the form. Basically, only putting the last piece of the route into the action attribute instead of the whole route. Why?
Any ideas on how to correct this?

You can work around this by overiding the form action as form1.Action = Request.Url.PathAndQuery;]in the Page_Load event

See this related Topic.
It uses Request.RawUrl instead of Request.Url.PathAndQuery, which seams to return the same value.

Related

Login to ASPX page with Perl script

I am trying to scrap an ASPX page with Perl's WWW::Mechanize . The problem is that the page I want to scrape can be accessed only after logging in. I tried using the HTML::TreeBuilderX::ASP_NET module but can't seem to get it to work.
I tried setting the __VIEWSTATE, __EVENTTARGET and __EVENTARGUMENT parameters.
Does anybody have any experience in logging into ASPX page using a Perl script?
Generally, you have to post the form (you'll only find one, typically, on any given aspx page; the form I'm talking about is the one found on login page) with all input values, including those hidden fields (especially those hidden fields, actually). the only values that you should change are uid/pwd textboxes. So, get the list of all named input tags, post them all; that should return a redirect with a asp.net auth cookie, which you have to include in subsequent requests.

How does Asp.net Knows which Page to Generate?

When a client is on page A.aspx , and he press some button there is a postback.
The server knows which page to rebuild according to the request.
but how does the client knows which page to re-ask ? by the current url of his browser ?
where this information is saved in the client side ?
Its defined in the action property of <form>. The client does not need to re-ask, the server sends a response of his request.
ASP.NET is just a part of the .NET framework, but what every client sees on a web browser in plain old HTML.
ASP.NET gives you several controls that makes it easy to use them programatically, so we can set all sort of things in our code (that is run before the page is showing) to do the exactly what we want.
every link, button, image, grid, it's just HTML tags, like <a> for links, <input type="button"> for buttons etc...
Keep in mind that now, there are 2 variantes of the ASP.NET, the WebForms and the MVC (you can also read about choosing one in prole of the other)
in every ASP.NET WebForms there is always a <form> on the start of the <body> and wrapps all your code, so, any submit will do a PostBack into the same file name, in your example A.apsx will always post into A.aspx, then if you want, for example, send that request to B.aspx you need to have a Click Event that would use the Server.Transfer("B.aspx") and that would redirect the entire post to B.aspx just like it was a post from B.aspx
in the newest pattern, the ASP.NET MVC, it drives with Routes witch let's you set up any, every, one, multiple, ways to reach the same page. In MVC the URL does not point to a specific page, but to a specific Controller and it's up to the Controller to send, after processing the data, to a specific View, that is why in MVC there are no pages in the url (though you can add it to the route if you want, and you can accomplish the same with WebForms using a Routing plugin).
Now, in MVC it's there is no <form> wrapping up your entire code, you need to, if you want to submit something, create your own <form> and point to the correct route
but, just like in Webforms or any HTML page, posts are made through form submittion, and it's "path" it's always whats in the form attribute action that let's you know what's the next step.
I hope this helps you realizing that there is no big monster in ASP.NET, that is only a way to reuse controls and access them programmatically and that, in the end, it's all HTML :)
A general answer: on the client side it's either a submit from within a form or a link.
The form points to either a relative URL (that means the current URL plays a key role) or an absolute URL (the current URL plays little to no role).
For links it's generally the same: either they are relative or absolute. One big difference: links are use HTTP GET while forms can use HTTP POST (thus transferring more data without encoding them to the URL as parameters).
For a button it's the form that gets submitted.

asp.net mvc expected controller and action not getting invoked

I have a weird issue. I loaded a page using "LoadMyPageController" and there is an ajax_submit_button1 which can be used submit the page.
Also there is another ajax_submit_button2 to print the page. This button submits the view model of the page as a whole to the "PrintController" which has a "PrintData" action.
Now when I hit the "ajax_submit_button2", my PrintController.PrintData is not invoked. Instead when I check my fiddler tool the request is made as
http://localhost:18484/LoadMyPage/PrintData?Length=14
which is an invalid URL.
I have contructed my ajax_submit_button2 in such a way that it should invoke
http://localhost:18484/Print/PrintData?Length=14
But I don't know why LoadMyPage controller is present in my URL.
Any thoughts or comments would be appreciated. By any chance does asp .net MVC decides that it will take a default controller on its own if it can't find the controller action for any reason.
The code is a kind of tightly coupled so can't post it. I want to know if anyone experienced a problem like this.
This has nothing to do with the routing on the server since the request being made by the client has the wrong controller in it. I suspect that your code generating the url for the submit button is not correct -- i.e., not specifying the controller to be used -- or that you have a form around the submit button that is actually being invoked instead of (or in addition to) the ajax code. Note that if your submit handler doesn't return false, the default form action will be invoked and the form submitted normally. If you do have a form, make sure that the url on it is correct and that your submit handler returns false.
$('#printForm').submit( function() {
$.ajax({
url: $(this).attr('action'),
...
});
return false; // this is important!
});

How do I use the "Post/Redirect/Get" a.k.a. "Redirect after Post" with asp.net

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

url rewriting + Asp.Net Login Form = Death

on our site we do url rewriting to generate massive amounts of database generated pages. on every page, there is a Login control for users. like this:
Internal aspx page: /DB.aspx?id=123
User visible url: /ABC/123.aspx, /ABC/456.aspx ... (url rewritten)
unfortunately, the tag on each page has an action attribute of "DB.aspx?id=123". when the user clicks the button the browser is posting to /ABC/DB.aspx?id=123 which of course does not exist.
solutions i tried:
1. change the action attribute by subclassing HtmlForm. this destroys the all other forms on the site.
2. remove the action attribute (so that the browser is always posting to the same url). this works on the rewritten pages but on "/" (the default.aspx in the root dir) i get a message that the verb post is not allowed on "/" (iis 6 and i have no control over mappings)
anybody?
Check this really nice blog post from scott gu, http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx.
"Specifically, you can take advantage of the new ASP.NET 2.0 Control Adapter extensibility architecture to customize the rendering of the control, and override its "action" attribute value with a value you provide. This doesn't require you to change any code in your .aspx pages"
Check the section: "Handling ASP.NET PostBacks with URL Rewriting", I have used the adapter he posted successfully.
Ps. be aware there are some issues on asp.net when using url rewrite when using cookieless session, and the rewritten url is deeper than the original page, just like the one you have. (/abc/apage vs. /db?). The issue is right into the source code of the framework, there are workarounds but that's a whole subject (with tradeoffs :( ... you might want to have them at the same level).
Semantics maybe, but does the action attribute = "DB.aspx?id=123" or "/DB.aspx?id=123"? Assuming your URL rewriting allows pass-through to physical pages, this might be your issue.
I never did it, but I saw the code using Reflector and I guess you can fix it this way:
On the page:
this.Form.Action = null;
or:
this.Form.SetAttribute("action", null);
If that doesn't work, just set the path you want:
this.Form.SetAttribute("action", "ABC/123.aspx");
If you upgrade to ASP.NET 3.5 SP1, the action property is now properly recognized and can be set from codebehind.

Resources