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.
Related
Some part of my site is Asp and the other is Asp.Net.
I use session to save the information of current user in Asp pages.
However,the session is lost on redirecting to an Asp.net page.
Sometimes,the session would be saved in the first redirecting Asp.net page.
After a while, I click a button and find that session is still lost.
I am really confused about this situation.
How could this happen?
ps:
1.I have checked the time-out configuration, it seems to work well.
2.The cookie configuration in brower looks normal.
ASP and ASP.NET do not share Session state. They are completely different systems.
If you want to share Session state somehow between the two systems, you can use the method outlined in this article: http://msdn.microsoft.com/en-us/library/aa479313.aspx
In ASP.NET which event fires when page is loaded in clients browers. Init, Load, PreRender event fires when page is not loaded in clients browser. Basically I have to some work when page is displayed in client's browser..
Instead of ASP.NET (server-side code) you might be more interested in Javascript (perhaps using jQuery's document.ready() which runs when the page has completed loading.)
Edit: The best answer I can come up with using only ASP.NET is OnLoadComplete()
There is no event like that. To understand why you have to understand how a web application works. The ASP.NET code runs on the server to build the contents of the web page, then the server sends the contents down to the browser which is running on the user's machine.
So the document being opened in the browser isn't even part of the ASP.NET page lifecycle. As far as ASP.NET is concerned, that page is now the browser's problem and it has already moved on to something else.
To make an analogy, it is like wanting to be notified when someone receives a letter that you (ASP.NET) mailed to them. Unless the recipient (the Browser) sends back some kind of communication there is no way for the sender (ASP.NET) to know what is happening somewhere else.
If you want to do something when the page is loaded in the browser, you need to write code that is run by the browser. Usually this is in the form of a script embedded in the page, usually in JavaScript.
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 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.
I was wondering if it is possible to do a RedirectToProvider and have the resulting OpenID provider page displayed in an iFrame. This would make the authentication flow seem a lot more streamlined.
I am using the DotNetOpenID library in ASP.NET MVC (VB).
This next part is sort of a seperate question, but is related.
I am using Ajax.BeginForm for the OpenID sign in form, however the RedirectToProvider fails here for some reason. Does DotNetOpenId not work with MVC and AJAX?
Yes, DotNetOpenId supports iframes, MVC and Ajax. The OpenIdAjaxTextBox control that ships with the library and is shown used in one of the samples demonstrates this. It does not use iframes to display anything. It uses them with checkid_immediate to attempt implicit login without any user interaction, which is the only iframe-scenario that OpenID intends to support.
The IAuthenticationRequest.RedirectToProvider method internally invokes the ASP.NET Response.Redirect, which itself throws a ThreadAbortException, which might be why it seems to be failing for you, when in fact it's probably working by design, but that design conflicts with what you're probably trying to do.
There are various approaches to take to get what you want done, but as Workshop Alex has already suggested, there is a security concern with hosting the Provider's page in an iframe. It's not that the RP can access or mettle with the content of the iframe, because as EFraim said unless the browser has bugs that would not be allowed anyway. The two problems with it are Clickjacking and that you're training the user to be phished, since he will likely be providing his login credentials to his OP while the RP's URL is in the location bar, which is a bad thing.
And in fact, major OPs now deliberately refuse to work when they are activated within an iframe, so after the work to get it all to behave the way you want, you'd likely be disappointed that most of your customers won't be able to login.
Also as you point out, popup windows, when done properly, can help keep the experience user friendly. You can achieve this a few different ways with DotNetOpenId as well. The ASP.NET controls that come with the library have this feature built in and can be activated by just setting a property on the control. But since you're using ASP.NET MVC (I think), here's how you can do it yourself:
When the user clicks the Login button on your page, rather than POSTing to the current window, have Javascript that opens an appropriately sized popup window at a URL like http://yoursite.com/openid/redirect?id=userSuppliedIdentifier.
Your OpenID controller's Redirect action will read that ID, do an OpenIdRelyingParty.CreateRequest on that ID, and return IAuthenticationRequest.RedirectingResponse.AsActionResult() (MVC style). Note you can pass your own URL to CreateRequest for a returnTo url if you want the OP's response to come back to a different method on your OpenID controller.
When the assertion comes back, your controller should send down javascript that closes the popup window and (as necessary) communicates back to the main window to update its state for the logged in user.
This whole process is completely automated in the ASP.NET controls that DotNetOpenId ships with. It's unfortunate that ASP.NET MVC cannot be made as modularized as ASP.NET web forms so that you don't have to do all this work yourself. Of course, the MVC sample that DotNetOpenId ships with could be made to show how to do popup behavior in a future version. If you want that, file a wish for it.
Question is, would the OpenID provider consider this a security risk or not? If the provider page is inside an IFrame then the surrounding page can have some control over what's happening inside this frame, including an attempt to capture some of the information. It could be a possible exploit risk. Do keep in mind that OpenID providers are very paranoid about these things and might even attempt to break out from such an IFrame or just deny any further login actions. It's a risk that they might not want to take.
Is it possible? If it is, I think the answer also depends on the provider.