I have a few questions about cross-page posting in ASP.NET:
What is cross-page posting in ASP.NET?
When should I consider using it in my web application?
What are pros and cons of cross-page posting?
Basically, cross-page posting means that you are posting form data to another page as opposed to posting form data back to the same page (as is the default in ASP.NET). This can be useful when you want to post data to another page and don't want to incur the overhead of reloading the current page simply to redirect the user to another page via an HTTP 302 (i.e. Response.Redirect).
For a more information please see Cross-Page Posting in ASP.NET Web Pages:
By default, buttons and other controls
that cause a postback on an ASP.NET
Web page submit the page back to
itself. This is part of the round-trip
cycle that ASP.NET Web pages go
through as part of their normal
processing. For details, see
Introduction to ASP.NET Web Pages.
Under some circumstances, you might
want to post one page to another page.
For example, you might be creating a
multi-page form that collects
different information on each page. In
that case, you can configure certain
controls (those that implement the
IButtonControl interface, such as the
Button control) on the page to post to
a different target page. This is
referred to as cross-page posting.
Cross-page posting provides some
advantages over using the Transfer
method to redirect to another page.
For details, see Redirecting Users to
Another Page.
Cross - page posting is targeting a different page from the original page. ASP.NET is based on the post-back model where the same page that sent it to you processes the response.
COnsider using it when you have lots of entry points that need the same processing.
Pros: single point of handling common routine
Cons: pages are hard-linked and have intimate knowledge. AKA coupling.
Related
We have a scenario at my work place where we need to post data from classic ASP page to ASP.Net form. Now this posting have some XSS vulnerabilities. I am just not sure how to resolve the issue. Scenario is classic ASP page post date to ASP.Net form which is a file inside MVC website. Then on page load event of that page, it gets all hidden variables values and create html from in Response and submit the same using frm.submit() JS code. So because of this middle asp.net page, it is open to attacks.
Any help appreciated.
Use Server.HTMLEncode() to encode the data written to your page if you're worried about XSS.
Is there a particular reason you rebuild this page at all? So long as you are using just the post method of the form on the classic asp page then you should not need to rebuild the form in .NET you could simply read the post response values.
Although this is pretty old, but I used AntiXSS library provided by Microsoft to prevent XSS.
I have to convert a few ASP pages (to ASP.net) that set values for hidden input values from a database and does a POST to an ASP page hosted on a vendors website.
I already have found that ASP.net pages can post to webpage other than themselves... My question is in regards to compatibility problems with the sending end being ASP.net and the recieving end being classic ASP. Is it possible to post from an ASP.net page to a classic ASP page that's on the vendors site?
Yes, it's quite possible.
POST is a request mechanism defined by the HTTP protocol - it's technology agnostic. A web page at the end of the day is just a bunch of HTML and script, regardless of the technology that rendered it.
You may get some extra data that ASP.Net puts into your forms, but otherwise there's no reason you can't post to any web address you want. Note that you won't be sharing session state or application variables, and you may have to manually construct a form or write your own form control (the regular pattern of having one form tag with "runat=server" won't help, because this sets it up to do a postback).
Hello friends it may sound awkward but i am novice to asp dotnet web development realm, so my question is genuine. Please explain me about what is postback in asp.net. I want it's practical meaning and how does it work in the page life cycle while i dp understand ispostBack and i use it as well.
But i am not getting good meaning of post back please explain it to me with good example.
The wikipedia page on Postback has the answers:
In the context of ASP web development, a postback is another name for HTTP POST. In an interactive webpage, the contents of a form are sent to the server for processing some information. Afterwards, the server sends a new page back to the browser.
This is done to verify passwords for logging in, process an on-line order form, or other such tasks that a client computer cannot do on its own. This is not to be confused with refresh or back actions taken by the buttons on the browser.
For more detail on the page life cycle, see MSDN, there is quite a lot of detail here.
Check this out:
http://www.codersource.net/asp-net/asp-net-articles/working-with-post-back-in-asp-net.aspx
Check out the introductory videos on http://www.asp.net/web-forms especially the one titled Page Lifecycle Events
A postback is when a web page post a form back to the same URL.
Historically, a web form would post to the next page, so a search form for example would post to the results page, not back to the search form.
The ASP.NET web forms rely heavily on postbacks to create an environment that is close to how a windows form application works. By posting back to the same page, it can have server events that seem to react to actions in the browser. Clicking a button will cause a postback, and the browser will load the same page again, with only the changes that the button click event caused.
I'm a PHP developer who has to work on ASP.net projects and I'm wondering why every page is wrapped in a form. This just doesn't make sense to me.
Also What's with all the hidden input fields especially the "View State" one.
ASP.Net tries to make it so that the programmers can pretend that the web is a stateful platform, and that it behaves like a desktop application. The ViewState is basically a serialized block of the state of the page when it was generated. When the page gets posted back the server side model gets initialized to the values in ViewState, and then the new values from the posted form are applied.
Part of becoming a decent ASP.Net programmer is learning when to use ViewState and not, because the default is to use it everywhere which causes a lot of bloat in the downloaded page.
Every ASP.NET page is wrapped in a <form> element because the entire framework revolves around POST commands.
ASP.NET provides 'web controls' which are object-oriented abstractions of HTML elements (and in some cases, groups of elements) - in your server-side code you can attach commands to various events on web controls (for example, Button.OnClick, TextBox.OnChanged) - the framework wires these up using a combination of hidden fields and generated javascript. The generated javascript typically sets a hidden field few values to indicate (for example) which control triggered the post and the command arguments (if applicable), then submits the form.
ViewState is a technique used by the framework to serialize client state. It's an alternative to using session heavily, trading larger HTML payloads for a lower memory footprint on the server.
Everything in ASP.NET (aspx pages) works off of posting data.
This means that anything you place on the web page with a server-side action will cause a "post back" to itself. The post back contains information such as "what just happened" and some information that helps the web page to maintain state (which web pages don't traditionally do). The view state is part of that task of maintaining state.
If you don't like the way aspx pages try to turn web-pages into forms-style stateful applications, you can try out the ASP.NET MVC framework, which lets the web work as intended!
ASP.NET WebForms engine creates a stateful abstraction over stateless HTTP.
The key object is a server page. Controls fire events that are processed server-side. Controls maintain their states (usually, input values) between requests.
Any time you click a server control, a "postback" request is sent back to the server. ViewState actually contains the data telling the server what control fired the event. That is why there is always a form (and any more forms are not allowed).
I'm very new to the whole Ajax/Asp.Net stuff so...
I know that there are at least a few different ways of implementing the server-side of an Ajax enabled Asp.Net site.
One way is to add static methods to your aspx page's code-behind and mark them with the WebMethod attribute.
Another way is to use a separate ASMX web service file (which I don't know anything about :) ).
What are the most commonly used options for implementing the server-side? What advantages and drawbacks does each one have? And how does each one fare from a security and session perspective? (Making sure the server knows which session the Ajax request is from and ensuring only logged-in users are responded to?)
Typically I like to use jQuery to make the requests to .ashx page that is responsible for reading the data and passing back the JSON to the page to deal with. It sounds like the other options you suggested are pretty complicated by comparison.
The two most commonly used options are
Microsoft ASP.Net AJAX
JQuery partnered with webservices or request handlers (like Jon's answer)
Microsoft's ASP.Net AJAX is a framework that revolves around two server controls - the ScriptManager and the UpdatePanel. It's a bit more heavyweight than other options, but it's certainly a simple way of ajaxifying your site. You simply use an UpdatePanel to surround the portion of the page that you wish to be asynchronous, and all your controls that do postbacks (buttons, links, etc.) automatically become asynchronous requests that will only update that portion of the page. No coding or anything.
If you do plan on using the webservice route, ASMX is not the way to go - it's basically a "legacy" technology at this point and you should consider using WCF services instead.