Why does asp.net wrap the page in a form? - asp.net

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).

Related

Adding features around Classic ASP Application

I will be adding new pages and adding functionality to current pages.
I would basically like to use new technology and but I don't know how should I add it to classic ASP pages
In other words, can I <#--include--> an aspx page in Classic asp page? Or anything of that sort, may be creating a user control in ASP.NET and using it in classic ASP?
You shouldn't really add it to the existing classic ASP pages. You may want to perform a full (yet slow) migration from classic ASP to .Net. Otherwise, you may just simply want to add your new functionality in new pages completely. If you have a templated site, this may become a litle cumbersome because you will need to recreate those templates in .Net since mixing .Net and classic in the same file is not possible.
You could ultimately end up resorting to iframes, but this makes browsers goofy sometimes. If your application is dependent on session, you'll need to account for that because .Net can't access a classic session unless you stick to primitives (string/int/etc) and use an outside state provider (like SQL) to hold the data with a sessionid that can be passed.
Having a hybrid site is a very tricky prospect and not one to be taken lightly. Tread carefully or you'll really put yourself in a pickle.
EDIT: Partial Hybrid example description
We had a 700 or so page site to transfer from classic asp to Asp.Net 2.0. Many of the pages were allotted time to be completely transferred during a single project, but a few areas were unable to be refactored and had to be accommodated. We put together a master page architecture for the new .Net structure, data library and business objects library, and we began the transfer. In incorporating the classic asp pages, we determined we had a few needs.
Since master pages would control basic layout, menu, header, footer, we would need to remove these elements from any pages brought over.
New session requirements were incompatible with existing session capabilities.
Classic asp pages must still be required to obey .Net formsauthentication.
I solved these problems with the following solutions:
Our application is targeted at a specific customer, so we were able to determine browser requirements. This allowed us to employ an iframe to hold classic asp content/applications without worrying that the iframe would go crazy on us in Webkit or Firefox or whatever.
To accommodate the session requirements, we built a small encryption/decryption engine in .Net and in classic asp that enabled us to encrypt a "query string" to pass the session information back and forth. It wasn't super secure, just enough that the casual user would not be tempted to mess with data. In addition we had to build two translation files. The first translation file was a .Net library static method that would take the session data, extract the necessary pieces and create the query string. The second one was the classic asp version that was designed to read the query string, parse the data and create the session primitives directly.
Making the classic asp pages behave for .Net was a server management issue. To do this, using the formsauthentication attribute protection="All" is supposed to be sufficient, but I found it still did not cover items that had other handlers anticipated. So I added a wildcard mapping in IIS to handle all files. From the properties of the IIS website, choose "Home Directory" and click "Configuration". At the bottom of the next window is a "Wildcard application maps" box. Click insert and navigate to the version of .Net you use to find the aspnet_isapi.dll file. This will force all files to parse against this file (which is harmless except that it kicks up the authentication request).
I can't provide specific code samples because of NDA, but this should at least provide some ideas on where to go from here.
You can have classic ASP pages running inside an ASP.NET application. You can add your pages in ASP.NET

Server side caching doesn't work with HttpHandler

If we use an aspx page with a Caching Profile, the server caches images that are loaded with the aspx page. So if ten clients load the same image through the aspx page (same url), for one client the image is gotten out of the db, for the nine others it is cached.
When we use a HttpHandler, this doesn't happen. The image is always fetched from the database. We have tried all different settings without any success. (we have checked this link and have not been able to cache on server side).
I can't answer based on experience of using the caching profile, so I'm not sure if this helps.
Under the covers, ASP.NET WebForms are driven by HttpHandlers - written by MS (as you'd expect). When you write you own Http Handler you don't automatically get all the functionality that the System.Web.UI.PageHandlerFactory handler has (the one that by default looks after .aspx pages/requests) - you have to bring it in (or develop it) yourself.
Maybe this is the problem you have - maybe the Caching Profile capabilities are being leveraged by the aspx pages because the System.Web.UI.PageHandlerFactory is already "integrated" with it out of the box, where-as when you write your own they just aren't there (by default) - and hence the they don't work.

Asp.Net Server-side implementation options for Ajax site

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.

DotNetOpenID in an iFrame

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.

Accessible controls for ASP.NET

In my last job we ended up rewriting the complete ASP.NET stack (forms, controls, validation, postback handling, ajax library etc...) - the reason I was given was that the ASP.NET controls were not accessible enough, not were any of the third party controls that were assessed for the project.
Can anyone point me to good accessible ASP.NET controls that do ajax as well?
Failing that, how would you approach creating accessible, ajax enabled controls?
You could take a look at the 'App_Browsers' feature in .NET.
It gives you the opportunity to hook into the rendering engine for each control. The original intention for this was to be able to alter the HTML output of controls depending on the user's browser - but you can also do it for all browsers.
You could also take a look at these control adapters, which make the normal ASP.NET controls 'CSS Friendly'.

Resources