Application Security Testing: An Integral Part of DevOps
This article is a sample chapter (Chapter 3) from ASP.NET in 60 Minutes a Day, written Glenn Johnson, and published by Wiley.
The last chapter covered the setup and configuration of the development environment. The development environment is an important necessity and will make the rest of your development more enjoyable.
This chapter explores Web Forms. Web Forms bring the structure and fun back to Web development. This chapter starts by looking at the two programming models for ASP.NET. It then looks at how ASP.NET uses server controls and at the HTML (HyperText Markup Language) and Web server controls. It finishes by looking at view state and post back.
Web Forms are an exciting part of the ASP.NET platform. Web Forms give the developer the ability to drag and drop ASP.NET server controls onto the form and easily program the events that are raised by the control. Web Forms have the following benefits:
- Rendering. Web Forms are automatically rendered in any browser. In addition, Web Forms can be tweaked to work on a specific browser to take advantage of its features.
- Programming. Web Forms can be programmed using any .NET language, and Win32 API calls can be made directly from ASP.NET code.
- .NET Framework. Web Forms are part of the .NET Framework, therefore Web Forms provide the benefits of the .NET Framework, such as performance, inheritance, type safety, structured error handling, automatic garbage collection, and xcopy deployment.
- Extensibility. User controls, mobile controls, and other third-party controls can be added to extend Web Forms.
- WYSIWYG. Visual Studio .NET provides the WYSIWYG (what you see is what you get) editor for creating Web Forms by dragging and dropping controls onto the Web Form.
- Code Separation. Web Forms provide a code-behind page to allow the separation of HTML content from program code.
- State Management. Provides the ability to maintain the view state of controls across Web calls.
Classroom Q & A
A: Yes. ASP.NET is focused around the added functionality of server controls, but you can still use standard HTML tags with client-side script as you have done in the past. As you become more familiar with the Visual Studio .NET environment, you may choose to change some of your controls to server controls to take advantage of the benefits that server controls provide.
Q: Can I use ASP and ASP.NET pages on the same Web site? Can I use Session and Application variables to share data between the ASP and ASP.NET pages?
A: Yes and no. You can run ASP and ASP.NET Web pages on the same Web site; in order words, the pages can coexist. You cannot share application and session data between the ASP and ASP.NET pages, because the ASP and ASP.NET run under separate contexts. What you will find is that you will have one set of Session and Application variables for the ASP pages and a different set of Session and Application variables for the ASP.NET pages.
Q: It's my understanding that there are two types of server controls. Can both types of server controls be used on the same Web page?
A: Yes. Visual Studio .NET provides HTML and Web server controls. You can provide a mixture of these controls on the same page. These controls will be covered in this chapter.
A: No. ASP.NET requires server-side script to be written in the same language on a page-by-page basis. In addition, Visual Studio .NET requires a project to be written in a single server-side language.
Two ASP.NET Programming Models
People who are familiar with traditional ASP are accustomed to creating a single file for each Web page. ASP.NET supports the single-file programming model. Using the single-page programming model, the server code and the client-side tags and code are placed in the same file with an .aspx file extension. This doesn't do anything to help clean up spaghetti code, but the single-file model can be especially useful to ease the pain of migrating ASP code to ASP.NET.
The two-page model provides a separation of the server-side code and client-side HTML and code. The model offers the ability to use an .aspx page for the client-side presentation logic and a Visual Basic code-behind file with a .vb file extension for the server-side code.
This chapter starts by using the single-page model due to its simplicity. After most of the basic concepts are covered, the chapter switches to the two-page model. The two-page, or code-behind, model is used exclusively throughout the balance of the book due to the benefits it provides.
Simple ASP.NET Page
Using the single-page programming model, a simple Hello World page using ASP.NET can be written and saved to a file called vb.aspx containing the following:
<%@ Page Language="vb" %> <HTML> <HEAD><title>Hello World Web Page</title></HEAD> <body> <form id="Form1" method="post" runat="server"> <asp:TextBox id="Hi" runat="server"> Hello World </asp:TextBox> <asp:Button id="Button1" runat="server" Text="Say Hi"> </asp:Button> </form> </body> </HTML>
The first line of code contains the page directive, which contains the compiler language attribute. The compiler language attribute can only be used once on a page. If additional language attributes are on the page, they are ignored. Some language identifiers are shown in Table 3.1. If no language identifier is specified, the default is vb. The page directive has many other attributes, which will be covered throughout this book.
Note: The language identifiers that are configured on your machine may be found by looking in the machine.config file, which is located in the %systemroot%\\Microsoft.NET\Framework\version\CONFIG folder. The machine.config file is an xml configuration file, which contains settings that are global to your machine. A search for compilers will expose all of the language identifiers that are configured on your computer. Always back up the machine.config file before making changes, as this file affects all .NET applications on the machine.
The rest of the page looks like standard HTML, except that this page contains three server controls: the form, the asp:TextBox, and the asp:Button. Server controls have the run="server" attribute. Server controls automatically maintain client-entered values across round trips to the server. ASP.NET automatically takes care of the code that is necessary to maintain state by placing the client-entered value in an attribute. In some cases, no acceptable attribute is available to hold the client-entered values. In those situations, the client-entered values are placed into a <input type="hidden"> tag.
Table 3.1 ASP.NET Language Identifiers
|Visual Basic .NET||vb; vbs; visualbasic; vbscript|
|Visual C#||c#; cs; csharp|
|Visual J#||VJ#; VJS; VJSharp|
When the page is displayed in the browser, the text box displays the initial Hello World message. A look at the client-side source reveals the following:
<HTML> <HEAD><title>Hello World Web Page</title></HEAD> <body> <form name="Form1" method="post" action="vb.aspx" id="Form1"> <input type="hidden" name="__VIEWSTATE" value="dDwtMTc2MjYxNDA2NTs7Pp6EUc0BOodWTOrpqef KJJjg3yEt"/> <input type="text" name="Hi" value="Hello World" id="Hi" /> <input type="submit" name="Button1" value="Say Hi" id="Button1" /> </form> </body> </HTML>
The form server control was rendered as a standard HTML form tag with the action (the location that the data is posted to) set to the current page. A new control has been added automatically, called the __VIEWSTATE control. (More on the __VIEWSTATE control is provided in this chapter.) The asp:TextBox Web server control was rendered as an HTML text box and has its value set to "Hello World." The asp:button Web server control was rendered as an HTML Submit button.
If Hi Universe is typed into the text box and the button is clicked, the button will submit the form data to the server and return a response. The response simply redisplays the page, but Hi Universe is still in the text box, thereby maintaining the state of the text box automatically.
A glimpse at the client-side source reveals the following:
<HTML> <HEAD><title>Hello World Web Page</title></HEAD> <body> <form name="Form1" method="post" action="vb.aspx" id="Form1"> <input type="hidden" name="__VIEWSTATE" value="dDwtMTc2MjYxNDA2NTs7Pp6EUc0BOodWTOrpqe fKJJjg3yEt"/> <input type="text" name="Hi" value="Hi Universe" id="Hi" /> <input type="submit" name="Button1" value="Say Hi" id="Button1" /> </form> </body> </HTML>
Table 3.2 ASP.NET Server Tags
|<%@ Directive %>||Directives no longer need to be the first line in the code, and many new directives may be used in a single ASP.NET file.|
|<tag runat="server" >||Tags that have the runat="server" attribute are server controls.|
|<script runat="server" >||ASP.NET subs and functions must be placed inside the server-side script tag and cannot be placed inside the <% %> tags.|
|<%# DataBinding %>||This is a new tag in ASP.NET. It is used to connect, or bind, to data. This will be covered in more detail in Chapter 8, "Data Access with ADO.NET."|
|<%-- Server Comment --%>||Allows a server-side comment to be created.|
|<!-- #include -->||Allow a server-side file to be included in a document.|
|<%= Render code %>||Used as in-line code sections, primarily for rendering and <% %> a snippet of code at the proper location in the document. Note that no functions are permitted inside <% %> tags.|
The only change is that the text box now has a value of Hi Universe. With traditional ASP, additional code was required to get this functionality that is built into ASP.NET server controls.
Many changes have been made in the transition from ASP to ASP.NET. Table 3.2 shows server tags that are either new or have a different meaning in ASP.NET. Understanding these changes will make an ASP to ASP.NET migration more palatable.