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.
Related
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.
My application uses a single aspx page, and dynamically loads in master pages based on the url.
I have a few secured master pages that have forms that need to post html, so I have to set ValidateRequest="false". This of course isn't available in the #Master directive, only the #Page directive. I don't want to disable this security setting site-wide, so is there an alternate way of accomplishing this at the master page level?
I'm referring to the "A potentially dangerous Request.Form value was detected from the client" error message you get when posting a page with html markup.
I don't think I can use web.config either as it's the same physical url that's serving up the entire site.
My only thought is to use javascript to encode the input.
Thanks.
EDIT: Confused Request validation with Event Validation.
Why not set Page's ValidateRequest also, based on URL.
But just out of curiosity, why did you choose that approach? to have one content page and vary the master? Are you applying theming based on the URL?
As it seems you cannot set ValidateRequest property dynamically. It has to be set either in the page directive, or Web.config.
Try using Page.EnableEventValidation = true, if that gives the needed result.
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.
I have a wierd situation where I have an ASP.NET page that sends the user to the ASP page, and data is passed from one to the other via query string.
I've been assigned the task of changing this so that cookies are used instead of query strings.
I'm a little clueless here. Is this possible? How do I get started? Do I need to worry about anything special because one page is ASP.NET and the other ASP ? I also cannot be totally reliant on Javascript because of those once-in-a-while user visitors who have Javascript turned off.
This is pretty simple.
As long as you are not setting a 'Session Cookie', the cookie is set on the browser.
I'm doing it here...when the user logs in and wants me to remember his username:
Set the cookie in ASP.NET:
Response.Cookies.Add(new HttpCookie("RememberMeUserName", owner.Username));
View the value in ASP:
Response.Write(Request.Cookies("RememberMeUserName"))
Both the ASP.NET & ASP pages must be on the same domain name.
Ed B seems to have it - further reading available here:
http://ryangaraygay.com/blog/post/Updating-ASP-cookie-from-ASPNET-vice-versa.aspx
I also found this : http://www.eggheadcafe.com/tutorials/aspnet/198ce250-59da-4388-89e5-fce33d725aa7/aspnet-cookies-faq.aspx
With gotcha's concerning IE 6 and fixes! Also has information on how to store multiple values in them.
I am working in a CMS where we use tokens ( which is turned into a user control. Is there a way to add the user control into an attribute value for our template style?
example :
<div class="<$tokenName/$>" />
this currently outputs an encoded user control, which is then not parsed by IIS.
Short answer: this is not possible.
Longer answer...
It's not IIS's job to parse the control... that happens when IIS hands off the request to the ASP.NET engine. ASP.NET does a single-pass parse through your ASPX before the Page lifecycle even starts... this is why controls you delcare in the ASPX are available during the Init event. Whenever your CMS expands "$tokenName", you are far past the point at which ASP.NET is interpreting your markup.
If you're having trouble with that, here's a thought experiment for you: What happens when $token expands into a user control that has some other $token2 control embedded in it? And that control contains some other $token3? How many times are you going to try and parse/expand/interpret your markup?