Beginning Ajax with ASP.NET- P23 pot

Now that you have looked at how to integrate Atlas with server controls, in the next chapter, you are going to look at integrating Atlas with membership, profiles, and other services pro

<textBox targetElement=”textboxRequired”>

<validators>

<requiredFieldValidator errorMessage=”You must enter some text.” />

<typeValidator type=”Number” errorMessage=”You must enter a valid number.” />

<rangeValidator lowerBound=”10” upperBound=”20”

errorMessage=”You must enter a number between 10 and 20.” />

</validators>

</textBox>

<validationErrorLabel targetElement=”valRequired”

associatedControl=”textboxRequired” />

<validationGroup id=”formGroup” targetElement=”formGroup”>

<associatedControls>

<reference component=”textboxValue” />

<reference component=”textboxRequired” />

</associatedControls>

</validationGroup>

<label targetElement=”lblValid” visibilityMode=”Collapse”>

<bindings>

<binding dataContext=”formGroup” dataPath=”isValid”

property=”visible” />

</bindings>

</label>

<label targetElement=”lblInValid”>

<bindings>

<binding dataContext=”formGroup” dataPath=”isValid”

property=”visible” transform=”Invert” />

<binding dataContext=”lblInValid” dataPath=”text”

property=”text” transform=”onValidGroup” />

</bindings>

</label>

</components>

</page>

</script>

How It Works

In this example, take note of several things:

❑ Two divtags have been added The IDs for the div tags are lblValid, which contains the text

to display when all validators are satisfied with the input, and lblInValid, which contains the text to display when one or more validators are invalid

❑ AvalidationGrouphas been defined in the xml-scriptsection The validation group defines the controls that will be validated together

❑ The lblValidand lblInValidtags have been added to the xml-scriptsection A set of bindings is defined for each

Figure 11-6 shows the output of the group validation process

306

Chapter 11

Figure 11-6

Why would you want to group validators together? Obviously, each individual validator will fire However, there may be situations where the validation should be done together For example, it would

be valuable for checking required fields when a user signs up for a new service This is what the validationGroupcontrol in Atlas is for

Behaviors

A behavior is the name of the set of actions that can be performed based on events in DTHML These

events might be click, hover, mouseover,or other client-side events These sets of actions that are performed comprise features such as auto-completion and Drag and Drop In other words, behaviors are used to provide a more sophisticated UI and behavioral features beyond standard DHTML In Atlas, behaviors are defined as a collection on a client-side control In other words, the individual behaviors are attached to a client-side control

Try It Out Using Behaviors Take a look at some code that incorporates behaviors In this example, a clickbehavior is set on the lblHidelabel so that when it is clicked, the visibility of the displayDatalabel is set to false, and the displayDatalabel is hidden from view When the lblShowlabel is clicked, the visibility of the display Datalabel is set to true, and the displayDatalabel is displayed on the screen, if it is not already viewable

<atlas:ScriptManager runat=”server” ID=”ScriptManager1” />

<div>

<div id=”displayData”>This is the text that will be hidden and shown based on clicking the text below Pretty cool.</div>

307

Atlas Controls

<br />

<span id=”lblHide” >Hide</span>&nbsp;

<span id=”lblShow” >Show</span>

</div>

<script type=”text/xml-script”>

<page xmlns:script=”http://schemas.microsoft.com/xml-script/2005”>

<components>

<control targetElement=”displayData” cssClass=”start” />

<label targetElement=”lblHide”>

<behaviors>

<clickBehavior>

<click>

<setProperty target=”displayData”

property=”visible” value=”false” />

</click>

</clickBehavior>

</behaviors>

</label>

<label targetElement=”lblShow”>

<behaviors>

<clickBehavior>

<click>

<setProperty target=”displayData”

property=”visible” value=”true” />

</click>

</clickBehavior>

</behaviors>

</label>

</components>

</page>

</script>

Figure 11-7 shows the output of the preceding code Clicking Hide will hide the text, assuming that the code is visible Clicking Show will display the code, assuming that it is hidden The advantage to using behaviors in this way is that no programming must be done in the preceding code You don’t have to set

up any JavaScript onclick events or anything to that effect

Figure 11-7

308

Chapter 11

Resources Used

❑ Wilco Bauwer— Wilco Bauwer, a intern on the Microsoft Atlas team provided significant assis-tance in answering questions regarding many features in Atlas Wilco’s web site and blog are located at www.wilcob.com

❑ Nikhil Kothari— Nikhil provided several helpful articles on his blog regarding how to prop-erly use several features of Atlas Nikhil’s web site and blog are located at www.nikhilk.net

❑ Atlas Quickstarts— The Atlas web site is http://atlas.asp.net

❑ Forums on ASP.NET site— The forums are located at http://forums.asp.net

Summar y

In this chapter, you have been introduced some very new and important concepts These are

❑ Programming controls through Atlas

❑ Working with server controls

❑ Using data binding

❑ Using behaviors From these you have seen that there is a lot of functionality in the server controls Along with that func-tionality is the ability to extend the server control and add new funcfunc-tionality to the server controls The integration with the server controls is very important as it brings the server-side methodology of ASP.NET and allows it to provide significant client-side functionality

Now that you have looked at how to integrate Atlas with server controls, in the next chapter, you are going to look at integrating Atlas with membership, profiles, and other services provided by ASP.NET

309

Atlas Controls

Atlas Integration with ASP.NET Ser vices

Microsoft Atlas provides a mechanism to integrate with the services provided by ASP.NET The integration is provided for services such as:

❑ Authentication— Applications must be able to integrate with the ASP.NET authentication services if they are to let only the correct people in and to keep the incorrect users out

❑ Authorization— Applications must be able to control where a user is allowed to go within an application Authorization is the process of deciding if an application user is allowed to access a portion, or all, of an application It is typically based on authentication within an application as well as the roles that a user is assigned to

❑ Roles— Applications must be able to provide client-side role-based security Roles are typically used along with authorization

❑ Profiles— Applications must be able to provide integration with the ASP.NET profile services

In this chapter, we are going to look at how the client-side focus of Atlas integrates with the server-side ASP.NET services We’ll start by doing a little bit of background on the ASP.NET services and then moving into code and an explanation of how these services integrate with Atlas

The Atlas examples and code are based on the March/April CTPs of Atlas The March CTP is the first version of Atlas that comes with a “Go-Live” license for actual usage in a production applica-tion The April CTP is basically a set of bug fixes to the March CTP It is our intention to update these files with new versions as changes are made to Atlas The site for the files is http://

beginningajax.com.

Examining ASP.NET Ser vices

Before you dive into how Atlas supports authentication, some quick background on the ASP.NET ser-vices provided in version 2.0 of ASP.NET is in order These serser-vices are defined and provided by the ASP.NET 2.0 Provider Model It is possible for a developer to extend these services

Although it is possible to extend these services by creating custom providers, the examples in this chap-ter will use the default providers unless otherwise noted.

Authentication

In an ASP.NET application, authentication is the process of verifying that a user is who the user states that

he or she is Typical authentication has two parts — a mechanism to request credentials, such as a set of text boxes for inputting a user ID and password, and a data store, such as a database, to check those cre-dential against The user ID and password are checked against the data store on the initial request If the initial request is granted, the user is typically granted a token in the form of a browser-side cookie This browser-side cookie shows that the user has been granted access Subsequent checks involve examining the validity of the cookie

ASP.NET supports four types of authentication These are:

❑ Windows-based authentication— Windows-based authentication is controlled by IIS It is used mainly for internal web applications that run over an intranet, and provides authentication through a Windows-based server

❑ Basic authentication— Basic authentication is similar to Windows-based authentication from the user’s standpoint; however, it transmits its information in clear text

❑ Forms-based authentication— Forms-based authentication is a catchall type of authentication that

is primarily used to authenticate information against various data sources when a nonstandard data source is used It is used in a majority of non-intranet ASP.NET applications Forms authentica-tion provides a mechanism to authenticate users based on custom requirements and code and to then maintain the authentication token (browser cookie, munged URL, or something else)

❑ Passport authentication— With Passport authentication, the Microsoft Passport Service is used

If you have used the Microsoft Hotmail service, you are using the Passport Service With the Passport Service, the user ID and password are stored in a central location on the Internet This information is managed by Microsoft With Passport authentication, an application will pass the user ID and password to the Passport system for testing If successful, the Passport service will hand a token back, similar to forms-based authentication

Windows Authentication

Windows authentication, also referred to as integrated Windows authentication, uses the Windows oper-ating system account to test the user ID and password (also knows as credentials) against a Windows-based user store, such as Active Directory If a user makes a request against a web resource that requires Windows authentication, the user must either be logged into the domain that the server is running on, or they must log on to the domain when they attempt to access a protected page With Windows authenti-cation, the credentials used to test are stored in the Microsoft Active Directory database The validation

312

Chapter 12

is performed using the Kerberos protocol A major advantage to this authentication scheme is that the password is not sent over the wire If a user is not already authenticated to a resource, the user is pre-sented with a browser pop-up style window for inputting a user ID/password combination

Although this is a fairly secure scheme it has several downfalls The main ones are:

❑ Users must be authenticated against the domain that the server is running against This would

be a large problem for remote users that are not logged on to the network

❑ Windows authentication is tightly associated with Windows and Internet Explorer While recent versions of the Mozilla Firefox web browser support Windows authentication when running on Windows, most developers identify Windows authentication as running only on Windows with Internet Explorer

Basic Authentication From the user’s standpoint, basic authentication is very similar to Windows authentication If a user is not authenticated to a resource (page, image, or such) that requires authentication, the user is presented with browser pop-up style windows for inputting a user ID/password combination Behind the scenes, there are significant differences between the two With basic authentication, passwords are sent over the network using base64 encoding, are embedded within HTTP, and are not encrypted in any way While not being quite as secure as Windows authentication, basic authentication is supported across multiple major web browsers and server products

Forms Authentication Forms authentication is similar to basic authentication The major difference is that Forms authentication allows a developer to define their own login pages, error pages, and resources to validate users against With Forms authentication, a login form is created for inputting user IDs and passwords A button on that form will call a routine to test for the user having the rights to access the resource ASP.NET pro-vides some built-in methods to test whether or not a user may get to a resource In addition, the devel-oper may substitute his or her own routines to validate the user

Passport Authentication Passport authentication uses the Microsoft Passport system This is a centralized authentication service provided by Microsoft It provides a single logon and profile services for member web sites Passport uses Triple DES encryption Unfortunately, the Passport authentication system has not been widely accepted outside of the Microsoft family of web sites and is no longer available as public service or for signup by non-Microsoft web sites

Authorization/Roles

Once a user has been authorized to use a web resource, the next step is authorization This allows

devel-opers to specify which resources application users are allowed to access within an application Grouping

users together to manage which resources they may access is referred to as role-based security This allows

for users to be grouped as necessary within an application, for example users, directors, application administrators, and other roles

313

Atlas Integration with ASP.NET Services

Within ASP.NET, the authorization rules may be stored within the Web.Configfile, database, external files, custom objects, or other locations

Membership

One of the “new” features of ASP.NET 2.0 is that user management capabilities are included in the box This new feature eliminates the need for writing all of the code necessary to manage users and passwords With ASP.NET 2.0, the logon controls provide the default implementation of the membership service The membership service provides two methods that are of significance These are:

❑ login— The loginmethod will validate the user against a data store and return the appropri-ate Forms authentication cookie

❑ validateUser— The validateUservalidates the users against a data store; however, it does not return a forms authentication cookie

Profiles

The profile service is a “new” feature of ASP.NET 2.0 The profile service provider supports the storage and retrieval of user-specific data within an application Profile information is stored within the

Machine.Configor the Web.Config Once the application’s profiles have been defined, the profile information is available through IntelliSense in Visual Studio NET 2005

Web Part Personalization

Web Parts are a new feature of ASP.NET 2.0 that moves web applications one step closer to acting like desk-top applications Web Parts allow an application to be customized by users at runtime This customization may include the layout of elements on the page as well as the selection of elements that actually appear on

a page The personalization service provides support for persisting Web Part configurations and support for storing the layout and location of Web Parts between sessions for individual users

Using Atlas to Integrate

with ASP.NET Ser vices

Now that you have looked at the basics of the services provided by ASP.NET, you can look at how these services are provided by Atlas

Authentication

Atlas provides support for Forms-based authentication This support is provided by the

Sys.Services.AuthenticationServicestatic class Inside of that class, there are two methods:

❑ login— This method maps to the configured membership provider’s loginmethod It contains several additional parameters The complete calling syntax is:

314

Chapter 12

login(username, password, OnLoginComplete, OnTimeOut, onError);

❑ validateUser— This method maps to the configured membership provider’s validateUser method This method is different from the previous method in one way In this method, the only thing that is not done is that if the username and password are accepted, a cookie is not set on the client web browser In addition to the username and password parameters, there are some additional parameters The complete calling syntax is:

validateUser(username, password, OnLoginComplete, OnTimeOut, onError);

Try It Out Using Atlas to Perform Authentication Take a look at some source for performing authentication:

<atlas:ScriptManager runat=”server” ID=”ScriptManager1” />

<form id=”form1” runat=”server”>

<div>

<table border=”1”>

<tr>

<td>User Id:</td>

<td><input type=”text” id=”txtUserId” name=”txtUserId” /></td>

</tr>

<tr>

<td>Password:</td>

<td><input type=”password” id=”txtPassword” name=”txtPassword” /></td>

</tr>

<tr>

<td colspan=”2”>

<input type=”button” id=”btnAuth” name=”btnAuth” onclick=”AuthTest()” value=”Auth Test” />

</td>

</tr>

</table>

</div>

<script language=”javascript”>

function AuthTest() {

var UserId = document.forms[0].txtUserId.value;

var PassWord = document.forms[0].txtPassword.value;

var authObj = Sys.Services.AuthenticationService;

authObj.login( UserId, PassWord, OnAuthTestComplete, OnAuthTestTimeOut, OnAuthTestError);

} function OnAuthTestComplete(result) {

if (null == result) {

alert(“Auth Test Complete Null Result”);

} else { alert(“Auth Test Complete Result: “ + result);

if(true == result)

315

Atlas Integration with ASP.NET Services