Professional ASP.NET 3.5 in C# and Visual Basic Part 108 pdf

Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1028
Chapter 21: Security
are configured. Highlight
.aspx
in the list of mappings and click the Edit button. Figure 21-16 shows
the result.
In the Executable text box, you can see that all
.aspx
pages map to the
aspnet_isapi.dll
from ASP.NET,
and that you can also specify which types of requests are allowed in the application. You can allow either
all verbs (for example,
GET
or
POST
) or you can specify which verbs are allowed access to the application.
One important point regarding these mappings is that you do not see
.html
,
.htm
,
.jpg
,orotherfile
extensions such as
.txt
in the list. Your application will not be passing requests for these files to ASP
.NET. That might not be a big deal, but in working through the various security examples in this chapter,
you might want to have the same type of security measures applied to these files as to
.aspx
pages. If,

for instance, you want all
.html
pages to be included in the forms authentication model that you require
for your ASP.NET application, you must add
.html
(or whatever file extension you want) to the list. To
do so, click the Add button in the Application Configuration dialog.
In the next dialog, you can add the ASP.NET DLL to the Executable text box, and the appropriate file
extension and verbs to the list before adding the mapping to your application’s mapping table. This
example is illustrated in Figure 21-17.
Figure 21-17
When dealing with the security of your site, you have to remember all the files that might not be included
in the default mapping list and add the ones you think should fall under the same security structure.
If you are working with Windows Vista, you can get to the same functionality through the IIS Manager.
In this tool, select Handler Mappings in the IIS section. You will find a large list of mappings that have
already been provided. This is illustrated in Figure 21-18.
By highlighting the
*.aspx
option and pressing the Edit button, you see that this extension is mapped to
%windir%
\
Microsoft.NET
\
Framework
\
v2.0.50727
\
aspnet_isapi.dll
, as shown in Figure 21-19.
Pressing the Request Restrictions button provides a dialog that enables you to select the verbs allowed

(as shown in Figure 21-20).
1028
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1029
Chapter 21: Security
Figure 21-18
Figure 21-19
1029
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1030
Chapter 21: Security
Figure 21-20
Figure 21-21
1030
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1031
Chapter 21: Security
Using the ASP.NET MMC Snap-In
The ASP.NET MMC console (covered in more detail in Chapter 34) enables you to edit the
web.config
and
machine.config
files using an easy-to-use GUI instead of having to dig through the text of those
files yourself to make the necessary changes. This option is only available in either Windows Server 2003
or Windows XP. Most of the items examined in this book can also be modified and changed using this
dialog. The plug-in is available on the ASP.NET tab (see Figure 21-21) of your Web application running
under IIS.
When you make the changes directly in the dialog, you are also making the hardcoded changes to the
actual configuration files.
Click the Edit Configuration button on the ASP.NET tab, and the ASP.NET Configuration Settings dialog
opens. There you can modify how your forms authentication model works in the GUI without going
to the application’s
web.config

file directly. Figure 21-22 shows an example of working with forms
authentication in the GUI.
Figure 21-22
1031
Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1032
Chapter 21: Security
Using the IIS 7.0 Manager
You will not find the ASP.NET MMC Snap In within Windows Vista. Instead, you will be able to make
all the same site modifications through the Internet Information Services (IIS) Manager (as shown in
Figure 21-23).
Figure 21-23
After making any changes through this dialog, you can select the Apply Changes link in the Actions
pane and it will notify you if t he changes made have been saved. When successful, the changes made a re
applied to the site’s
web.config
file.
Summary
This chapter covered some of the foundation items of ASP.NET security and showed you how to apply
both authentication and authorization to your Web applications. It reviewed some of the various authen-
tication and authorization models at your disposal, such as Basic, Digest, and Windows Integrated
Authentication. Other topics included forms-based authentication and how to construct your own
forms-based authentication models outside of the ones provided via ASP.NET 3.5 by using the member-
ship and role management capabilities it provides. The chapter also discussed how to use authentication
properties within your applications and how to authorize users and groups based on those properties.
1032
Evjen c22.tex V2 - 01/28/2008 3:19pm Page 1033
State Management
Why is state management such a difficult problem that it requires an entire chapter in a book on
programming? In the old days (about 15 years ago), using standard client-server architecture meant
using a fat client and a fat server. Perhaps your Visual Basic 6 application could talk to a database.

The state was held either on the client-side or in the server-side database. Typically, you could
count on a client having a little bit of memory and a hard drive of its own to manage state. The
most important aspect of traditional client/server design, however, was that the client was always
connected to the server. It’s easy to forget, but HTTP is a stateless protocol. For the most part,
a connection is built up and torn down each time a call is made to a remote server. Yes, HTTP
1.1 includes a keep-alive technique that provides optimizations at the TCP level. Even with these
optimizations, the server has no way to determine that subsequent connections came from the
same client.
Although the Web has the richness of DHTML and Ajax, JavaScript, and HTML 4.0 on the client
side, the average high-powered Intel Core Duo with a few gigabytes of RAM is still being used
only to render HTML. It’s quite ironic that such powerful computers on the client side are still so
vastly underutilized when it comes to storing state. Additionally, although many individuals have
broadband, it is not universally used. Developers must still respect and pay attention to the dial-up
users of the world. When was the last time that your project manager told you that bandwidth was
not an issue for your Web application?
The ASP.NET concept of a Session that is maintained over the statelessness of HTTP is not a new
one, and it existed before ASP.NET and even before classic ASP. It is, however, a very effective and
elegant way to maintain state. There are, however, a number of different choices available to you,
of which the ASP.NET session is just one. There have been a few subtle changes between ASP.NET
1.x and 2.0/3.5 that will be covered in this chapter. The
Session
objectremainsasbefore,butthe
option to plug in your own session state provider is now available.
Evjen c22.tex V2 - 01/28/2008 3:19pm Page 1034
Chapter 22: State Management
What Are Your Choices?
Given a relatively weak client, a stateless protocol such as HTTP, and ASP.NET on the server side, how
do you manage state on the Web? Figure 22-1 is a generalized diagram that identifies the primary means
available for managing state. The problem is huge, and the solution range is even larger. This chapter
assumes that you are not using Java applets or ActiveX controls to manage state. Although these options

are certainly valid (although complex) solutions to the state problem, they are beyond the scope of
this book.
Session
Application
ASP.Net worker process
Web server
Hidden HTML form
field and/or JavaScript
array
Cookies (HTTP headers)
http:// /page.aspx?state=some
State in the URL
Client Browser
Cache
OOP
session
state
Figure 22-1
If you remember one thing about state management, remember this: There is no right answer. Some
answers are more right than others, certainly; but there are many, many ways to manage state. Think
about your last project. How many days were spent trying to decide where you should manage state?
The trick is to truly understand the pros and cons of each method.
To make an educated decision about a method, you should understand the lifecycle of a request and the
opportunities for state management at each point in the process:
1. A Web browser makes an
HTTP GET
request for a page on your server,
http://myserver/
myapp/mypage.aspx
. This client Web b rowser has never visited your site before.

2. IIS and your ASP.NET application respond by returning HTML rendered by
mypage.aspx
.
Additionally
mypage.aspx
returns a cookie with a unique ID to track this Web browser.
Remember that a cookie is actually a slightly abstract concept. The cookie is set by return-
ing a Set-Cookie HTTP Header to the client. The client then promises to return the values of
the cookie in every subsequent HTTP call in the HTTP header. The state in this example is
actually an agreement between the client and server to bounce the cookie back-and-forth on
every request in response.
3. The HTML that is returned may contain hidden text boxes such as <
input type="hidden"
value="somestate"/
>. These text boxes are similar to cookies because they are passed back
to the server if the form on this page is submitted. Cookies are set per domain; hidden form
fields are set per page.
1034
Evjen c22.tex V2 - 01/28/2008 3:19pm Page 1035
Chapter 22: State Management
4. Upon the next request, the previously set cookies are returned to the server. If this request
was the submission of the form as an HTTP POST, all fields in the Form are returned —
hidden or otherwise.
5. The unique identifier that was set earlier as a cookie can now be used as a key into any kind
of server-side state mechanism. That state might be as simple as an in-memory hashtable, or
as complicated as a SQL database.
One of the repeating themes you might notice is the agreement between the client and the server to
pass information back and forth. That information can be in the URL, in HTTP headers, or even in the
submitted Form as an input field.
On the server side, you have a few options. You’ll want to weigh the options based on the amount of

memory you have available, the amount of data you want to store, and how often you’ll require access
to the data.
The following tables express each of the server-side and client-side options and list a few pros and cons
for each.
Server-Side Option Pros Cons
Application State Fast. Shared among all users. State is stored once per server in
multiple server configurations.
Cache Object
(Application Scope)
Like the Application State but
includes expiration via
Dependencies (see Chapter 23 on
caching).
State is stored once per server in
multiple server configurations.
Session State Three choices: in process, out of
process, DB-backed. Can be
configured as cookieless.
Can be abused. You pay a serialization
cost when objects leave the process. In
process requires Web Server affinity.
Cookieless configuration makes it
easier to hijack.
Database State can be accessed by any server
in a Web farm.
Pay a serialization and persistence cost
when objects leave the process.
Requires a SQL Server license.
On the client side, every available option costs you in bandwidth. Each option involves passing data back
and forth from client to server. Every byte of data you store will be paid for twice: once when it is passed

to the server and once when it is passed back.
Client-Side Option Pros Cons
Cookie Simple Can be rejected by browser. Not appropriate
for large amounts of data. Inappropriate for
sensitive data. Size cost is paid on every
HTTP Request and Response.
Hidden Field Simple for page-scoped data Not appropriate for large amounts of data.
Inappropriate for sensitive data.
1035
Evjen c22.tex V2 - 01/28/2008 3:19pm Page 1036
Chapter 22: State Management
Client-Side Option Pros Cons
ViewState Simple for page-scoped data Encoding of serialized object as binary
Base64-encoded data adds approximately 30
percent overhead. Small serialization cost.
Has a negative reputation, particularly with
DataGrids.
ControlState Simple for page-scoped
control-specific data
Like ViewState, but used for controls that
require ViewState even if the developer has
turned it off.
QueryString (URL) Incredibly simple and often
convenient if you want your
URLs to be modified directly
by the end user
Comparatively complex.Can’tholdalotof
information. Inappropriate for sensitive
data. Easily modified by the end user.
These tables provided you with some of the server-side and client-side options. The improvements to

caching in ASP.NET 2.0/3.5 are covered in Chapter 23.
Understanding the Session Object in ASP.NET
In classic ASP, the
Session
object was held in-process (as was everything) to the IIS process. The user
received a cookie with a unique key in the form of a GUID. The Session key was an inde x into a dictionary
where object references could be stored.
In all versions of ASP.NET the
Session
object offers an in-process option, but also includes an out-of-
process and database-backed option. Additionally, the developer has the option to enable cookieless
session state where the Session key appears in the URL rather than being sent as a cookie.
Sessions and the Event Model
The
HttpApplication
object raises a series of events during the life of the HTTP protocol request:
❑
BeginRequest
: This event fires at the b eginning of every request.
❑
AuthenticateRequest
: This event is used by the security module a nd indicates that a request is
about to be authenticated. This is where the security module, or you, determines who the user is.
❑
AuthorizeRequest
: This event is used by the security module and indicates that a request is
about to be authorized. This is where the security module, or you, determines what the user is
allowed to do.
❑
ResolveRequestCache

: This event is used by the caching module to determine whether this
now-authorized request can bypass any additional processing.
❑
AcquireRequestState
: This event indicates that all session state associated with this HTTP
request is about to be acquired.
1036
Evjen c22.tex V2 - 01/28/2008 3:19pm Page 1037
Chapter 22: State Management
Session state is available to you, t he developer, after the
AcquireRequestState
event
fires. The session state key that is unique to each user is retrieved either from a
cookie or from the URL.
❑
PreRequestHandlerExecute
: This is the last event you get before the
HttpHandler
class for this
request is called.
Your application code, usually in the form of a Page, executes at this point in
the process.
❑
PostRequestHandlerExecute
: This is the event that fires just after the
HttpHandler
is called.
❑
ReleaseRequestState
: Indicates that the session state should be stored. Session state is

persisted at this point, using whatever Session-state module is configured in
web.config
.
❑
UpdateRequestCache
: All work is complete, and the resulting output is ready to be added to
the cache.
❑
EndRequest
: This is the last event called during a request.
You can see from the preceding list that
AcquireRequestState
and
ReleaseRequestState
are two
significant events in the life of the
Session
object.
By the time your application code executes, the
Session
object has been populated using the Session key
that was present in the cookie, or as you see later, from the URL. If you want to handle some processing
at the time the Session begins, rather than handling it in
AcquireRequestState
, you can define an event
handler for the
Start
event of a SessionState HttpModule.
Sub Session_OnStart()
’this fires after session state has been acquired by the SessionStateModule.

End Sub
The
Session
object includes both
Start
and
End
events that you can hook event
handlers to for your own needs. However, the
Session_OnEnd
event is supported
only in the In-Process Session State mode. This event will not be raised if you use
out-of-process State Server or SQL Server modes. The
Session
ends, but your
handlers will never hear about it.
Pre- and post-events occur at almost every point within the life of an HTTP request. Session state can be
manipulated at any point after
AcquireRequestState
, including in the
Global.asax
within the
Session_OnStart
event.
The
HttpSessionState
object can be used within any event in a subclass of the
Page
object. Because
the pages you create in ASP.NET derive from

System.Web.UI.Page
, you can access Session State as a
collection because
System.Web.SessionState.HttpSessionState
implements
ICollection
.
1037