Thursday, September 29, 2005

[itsdifferent] IFlex Solutions In Afghanistan

Hi friends

I found this Amazing Site of Iflex SOlutions @ Afghanistan ....!!!

http://www.iflex.com.af/






Regards
Brijesh Pandya
Associate Consultant
: brijesh.pandya@iflexsolutions.com








Note: This Group is not a Job Searching Group, so please co-operate and dont transfer any kind of job related material across this Group.AnyOne doing so can be banned from the Group
Thanx , Group Co-Ordinators




SPONSORED LINKS
Computer software spy Automotive computer software Medical computer software
Computer telephony software Computer software online training Computer monitoring software


YAHOO! GROUPS LINKS




Wednesday, September 28, 2005

[itsdifferent] Accoona

Hi,
 
read about some search engine (ACCOONA) that claims to leverage AI for Search
 
-- joshi darshan


Note: This Group is not a Job Searching Group, so please co-operate and dont transfer any kind of job related material across this Group.AnyOne doing so can be banned from the Group
Thanx , Group Co-Ordinators




SPONSORED LINKS
Computer software spy Automotive computer software Medical computer software
Computer telephony software Computer software online training Computer monitoring software


YAHOO! GROUPS LINKS




Tuesday, September 27, 2005

[itsdifferent] Role-based Security with Forms Authentication

Role-based Security with Forms Authentication

Introduction

Forms Authentication in ASP.NET can be a powerful feature. With very little code and effort, you can have a simple authentication system that is platform-agnostic. If your needs are more complex, however, and require more efficient controls over assets, you need the flexibility of groups. Windows Authentication gives you this flexibility, but it is not compatible with anything but Internet Explorer since it uses NTLM, Microsoft's proprietary authentication system. Now you must choose how to manage your assets: provide multiple login pages / areas and force users to register for each, or assign groups to users and limit access to pages / areas to particular groups. Obviously, you must choose the latter.

Role-based security in Forms Authentication is one thing Microsoft left out in this round for .NET, but they didn't leave you high-and-dry. The mechanisms are there, they're just not intuitive to code. This tutorial will cover the basics of Forms Authentication, how to adapt it to make use of role-based security, and how to implement role-based security on your site with single sign-ons.

Prerequisites

This tutorial is all about role-based security with Forms Authentication, a detail that Microsoft left out of .NET for this round. This tutorial will use different techniques that are almost completely incompatible with the standard Forms Authentication, save the setup, which we'll cover shortly.

To follow along in this tutorial, you'll need to create a database, a web application, several secured directories, and a few ASP.NET Web Forms (pages).

Creating the Database

We will create a simple database containing a flat table for this tutorial. Using the <credentials/> section of the Web.config file is not an option because no mechanism for roles is supported. For the purposes of brevity, the table we create will be very simple. You're welcome to expand the database to make use of relations (what I would do and actual do use on several sites) for roles. The implementation does start to get a little messy depending on how you do it, and the details are left up to you. This is merely a tutorial about developing role-based security.

So, choose what database management system you want to use (DBMS). For this tutorial, we'll choose the Microsoft Data Engine (MSDE) available with Visual Studio .NET, Office XP Developer, and several other products. We'll add one database, say web, and then add one table, say users. To the users table, we'll add three fields: username, password, and roles. Set the username field to the primary key (since it'll be used for look-ups and needs to be unique), and optionally create an index on the username and password fields together. If you're using Table-creation SQL Scripts, your script might look something like this:

CREATE  DATABASE web  CREATE TABLE users ( 	username nvarchar(64) CONSTRAINT users_PK PRIMARY KEY, 	password nvarchar(128), 	roles nvarchar(64) )  CREATE INDEX credentials ON users ( 	username, 	password )

Feel free to add some credentials to your database, picking a few roles you think are good group names for your site, such as "Administrator", "Manager", and "User". For this tutorial, put them in comma-delimited format in the "roles" field like the following, pipe-delimited (|) table:

username|password|roles "hstewart"|"codeproject"|"Administrator,User" "joe"|"schmoe"|"User"

Take note to make the roles case-sensitive. Now let's move on to creating our pages necessary for role-based Forms Authentication.

Creating the Login Pages

If you haven't already done so, create a new Web Application, or attach to an existing Web Application, such as your web server's document root, "/". For this tutorial, we'll assume the Web Application resides in "/", though the procedure for any Web Application is the same.

Before we create any pages or setup our Web.config file, you must understand one thing: the login.aspx (or whatever you call your login page) must be public. If it isn't, your users will not be able to log-in, and could be stuck in an infinite loop of redirects, though I've not tested this and don't care to. So, this tutorial will assume that login.aspx is in "/", while we have two secured sub-directories, users and administrators.

First, we must create a Forms Authentication login system that supports roles. Because Microsoft did not provide for this easily, we will have to take over the process of creating the authentication ticket ourselves! Don't worry, it's not as hard as it sounds. A few pieces of information are needed, and the cookie has to be stored under the right name - the name matching the configured name for Forms Authentication in your root Web.config file. If these names don't match, ASP.NET won't find the Authentication Ticket for the Web Application and will force a redirect to the login page. For simplicity, we will put the code directly into the ASP.NET Web Form, which is easier to code for DevHood and should look something like the following:

<%@ Page Language="C#" %> <%@ Import Namespace="System.Data" %> <%@ Import Namespace="System.Data.SqlClient" %> <html> <head> 	<title>Login</title> </head> <script runat="server"> // If you're using code-behind, make sure you change "private" to // "protected" since the .aspx page inherits from the .aspx.cs // file's class private void btnLogin_Click(Object sender, EventArgs e) { 	// Initialize FormsAuthentication, for what it's worth 	FormsAuthentication.Initialize();  	// Create our connection and command objects 	SqlConnection conn = 	 new SqlConnection("Data Source=localhost;Initial Catalog=web;"); 	SqlCommand cmd = conn.CreateCommand(); 	cmd.CommandText = "SELECT roles FROM web WHERE username=@username " + 	 "AND password=@password";  	// Fill our parameters 	cmd.Parameters.Add("@username", SqlDbType.NVarChar, 64).Value = Username.Value; 	cmd.Parameters.Add("@password", SqlDbType.NVarChar, 128).Value = 	 FormsAuthentication.HashPasswordForStoringInConfigFile( 		Password.Value, "md5"); // Or "sha1"  	// Execute the command 	conn.Open(); 	SqlDataReader reader = cmd.ExecuteReader(); 	if (reader.Read()) 	{ 	 // Create a new ticket used for authentication 	 FormsAuthenticationTicket ticket = new FormsAuthenticationTicket( 		1, // Ticket version 		Username.Value, // Username associated with ticket 		DateTime.Now, // Date/time issued 		DateTime.Now.AddMinutes(30), // Date/time to expire 		true, // "true" for a persistent user cookie 		reader.GetString(0), // User-data, in this case the roles 		FormsAuthentication.FormsCookiePath);// Path cookie valid for  	 // Encrypt the cookie using the machine key for secure transport 	 string hash = FormsAuthentication.Encrypt(ticket); 	 HttpCookie cookie = new HttpCookie( 		FormsAuthentication.FormsCookieName, // Name of auth cookie 		hash); // Hashed ticket  	 // Set the cookie's expiration time to the tickets expiration time 	 if (ticket.IsPersistent) cookie.Expires = ticket.Expiration;  	 // Add the cookie to the list for outgoing response 	 Response.Cookies.Add(cookie);  	 // Redirect to requested URL, or homepage if no previous page 	 // requested 	 string returnUrl = Request.QueryString["ReturnUrl"]; 	 if (returnUrl == null) returnUrl = "/";  	 // Don't call FormsAuthentication.RedirectFromLoginPage since it 	 // could 	 // replace the authentication ticket (cookie) we just added 	 Response.Redirect(returnUrl); 	} 	else 	{ 	 // Never tell the user if just the username is password is incorrect. 	 // That just gives them a place to start, once they've found one or 	 // the other is correct! 	 ErrorLabel = "Username / password incorrect. Please try again."; 	 ErrorLabel.Visible = true; 	}  	reader.Close(); 	conn.Close(); } </script> <body> 	<p>Username: <input id="Username" runat="server" type="text"/><br /> 	Password: <input id="Password" runat="server" type="password"/><br /> 	<asp:Button id="btnLogin" runat="server" OnClick="btnLogin_Click" 	 Text="Login"/> 	<asp:Label id="ErrorLabel" runat="Server" ForeColor="Red" 	 Visible="false"/></p> </body> </html>

You'll notice above that we do one other thing with our passwords: we hash them. Hashing is a one-way algorithm that makes a unique array of characters. Even changing one letter from upper-case to lower-case in your password would generate a completely different hash. We'll store the passwords in the database as hashes, too, since this is safer. In a production environment, you'd also want to consider having a question and response challenge that a user could use to reset the password. Since a hash is one-way, you won't be able to retrieve the password. If a site is able to give your old password to you, I'd consider steering clear of them unless you were prompted for a client SSL certificate along the way for encrypting your passphrase and decrypting it for later use, though it should still be hashed.

Note: without using HTTP over SSL (HTTPS), your password will still be sent in plain-text across the network. Hashing the password on the server only keeps the stored password secured. For information about SSL and acquiring a site or domain certificate, see http://www.versign.com/ or http://www.thawte.com/.

If you don't want to store hashed passwords in the database, change the line that reads FormsAuthentication.HAshPasswordForStoringInConfigFile(Password.Value, "md5") to just Password.Value.

Next, we'll need to modify the Global.asax file. If your Web Application doesn't have one already, right-click on the Web Application, select "Add->Add New Item...->Global Application Class". In either the Global.asax or Global.asax.cs (or Global.asax.vb, if you're using VB.NET), find the event handler called Application_AuthenticateRequest. Make sure it imports / uses the System.Security.Principal namespace and modify it like so:

protected void Application_AuthenticateRequest(Object sender, EventArgs e) {   if (HttpContext.Current.User != null)   { 	if (HttpContext.Current.User.Identity.IsAuthenticated) 	{ 	 if (HttpContext.Current.User.Identity is FormsIdentity) 	 { 		FormsIdentity id = 			(FormsIdentity)HttpContext.Current.User.Identity; 		FormsAuthenticationTicket ticket = id.Ticket;  		// Get the stored user-data, in this case, our roles 		string userData = ticket.UserData; 		string[] roles = userData.Split(','); 		HttpContext.Current.User = new GenericPrincipal(id, roles); 	 } 	}   } }

What's happening above is that since our principal (credentials - which are your username and roles) is not stored plainly as part of our cookie (nor should it, since a user could modify their list of role-memberships), it needs to be generated for each request. The FormsAuthenticationTicket is actually encrypted as part of a cookie using your machine key (usually configured in machine.config) and the FormsAuthentication module decrypts the tick as part of the user's identity. If you search long and hard enough on Microsoft MSDN web site, you'll find this documentation buried. We use the UserData to obtain the list of roles and generate a new principal. Once the principal is created, we add it to the current context for the user, which the receiving page can use to retrieve credentials and role-memberships.

Securing Directories with Role-based Forms Authentication

To make the role-based authentication work for Forms Authentication, make sure you have a Web.config file in your Web Application root. For the authentication setup, this particular Web.config file must be in your Web Application's document root. You can override the <authorization/> in Web.config files for sub-directories.

To begin, make sure your Web.config file has at least the following:

<configuration> 	<system.web> 		<authentication	mode="Forms"> 			<forms name="MYWEBAPP.ASPXAUTH" 				loginUrl="login.aspx" 				protection="All" 				path="/"/> 		</authentication> 		<authorization> 			<allow users="*"/> 		</authorization> 	</system.web> </configuration>

The FormsAuthentication name (MYWEBAPP.ASPXAUTH) above it arbitrary, although the name there and the name in the HttpCookie we created to hold the hashed FormsAuthenticationTicket must match, for even though we are overriding the ticket creation, ASP.NET still handles the authorization automatically from the Web.config file.

To control authorization (access by a particular user or group), we can either 1) add some more elements to the Web.config file from above, or 2) create a separate Web.config file in the directory to be secure. While, I prefer the second, I will show the first method:

<configuration> 	<system.web> 		<authentication mode="Forms"> 			<forms name="MYWEBAPP.ASPXAUTH" 				loginUrl="login.aspx" 				protection="All" 				path="/"/> 		</authentication> 		<authorization> 			<allow users="*"/> 		</authorization> 	</system.web> 	<location path="administrators"> 		<system.web> 			<authorization> 				<!-- Order and case are important below --> 				<allow roles="Administrator"/> 				<deny users="*"/> 			</authorization> 		</system.web> 	</location> 	<location path="users"> 		<system.web> 			<authorization> 				<!-- Order and case are important below --> 				<allow roles="User"/> 				<deny users="*"/> 			</authorization> 		</system.web> 	</location> </configuration>

The Web Application always creates relative paths from the paths entered here (even for login.aspx), using it's root directory as the starting point. To avoid confusion with that condition and to make directories more modular (being able to move them around without changing a bunch of files), I choose to put a separate Web.config file in each secure sub-directory, which is simply the <authorization/> section like so:

<configuration> 	<system.web> 		<authorization> 			<!-- Order and case are important below --> 			<allow roles="Administrator"/> 			<deny users="*"/> 		</authorization> 	</system.web> </configuration>

Notice, too, that the role(s) is/are case-sensitive. If you want to allow or deny access to more than one role, delimit them by commas.

That's it! Your site is setup for role-based security. If you use code-behind, compile your application first. Then try to access a secure directory, such as /administrators, and you'll get redirected to the login page. If login was successful, you're in, unless your role prohibits it, such as the /administrators area. This is hard for the login.aspx page to determine, so I'd recommend a Session variable to store the login attempts and after so many times, return an explicit "Denied" statement. There is another way, however, which is discussed below.

Conditionally Showing Controls with Role-based Forms Authentication

Sometimes it's better to show / hide content based on roles when you don't want to duplicate a bunch of pages for various roles (user groups). Such examples would be a portal site, where free- and membership-based accounts exist and membership-based accounts can access premium content. Another example would be a news page that would display an "Add" button for adding news links if the current user is in the "Administrator" role. This section describes how write for such scenarios.

The IPrincipal interface, which the GenericPrincipal class we used above implements, has a method called IsInRole(), which takes a string designating the role to check for. So, if we only want to display content if the currently logged-on user is in the "Administrator" role, our page would look something like this:

<html> <head>   <title>Welcome</title>   <script runat="server">   protected void Page_Load(Object sender, EventArgs e)   {    if (User.IsInRole("Administrator"))     AdminLink.Visible = true;   }   </script> </head> <body>   <h2>Welcome</h2>   <p>Welcome, anonymous user, to our web site.</p>   <asp:HyperLink id="AdminLink" runat="server"    Text="Administrators, click here." NavigateUrl="administrators/"/> </body> </html>

Now the link to the Administrators area of the web site will only show up if the current user is logged in and is in the "Administrator" role. If this is a public page, you should provide a link to the login page, optionally setting the QueryString variable called ReturnUrl to the path on the server you want the user to return to upon successful authentication.



Note: This Group is not a Job Searching Group, so please co-operate and dont transfer any kind of job related material across this Group.AnyOne doing so can be banned from the Group
Thanx , Group Co-Ordinators




YAHOO! GROUPS LINKS




[itsdifferent] Opera Is Free

hi all,

Opera has removed the banners, found within our
browser, and the licensing fee. Opera's growth, due to
tremendous worldwide customer support, has made
today's milestone an achievable goal. Premium support
is available.

recently opera has annonced that they will give
opera 8.5 free.(without banner or ads)
and it is free as i have using it
so download it from here

visit  http://opera.com/


thanks

Chauhan Yatin
GSM:- +91-(9824)-228276
http://photos.yahoo.com/chauhan_yatin [free 2 use]
http://www.YQwe.com
Excess of anYthing is bad. Horizon is our limit.



           
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com




Note: This Group is not a Job Searching Group, so please co-operate and dont transfer any kind of job related material across this Group.AnyOne doing so can be banned from the Group
Thanx , Group Co-Ordinators




SPONSORED LINKS
Computer software spy Automotive computer software Medical computer software
Computer telephony software Computer software online training Computer monitoring software


YAHOO! GROUPS LINKS




Monday, September 26, 2005

Re: [itsdifferent] Satellite Images of Weather

Also, look at the one...
 
- dgoyani

Deven Goratela <dev_khatri@yahoo.com> wrote:
Hello Its-Differents,

Follow this link
http://www.imd.ernet.in/section/satmet/dynamic/insat.htm
to see the Satellite Images of Weather in India in Different
Categories. Its updated daily.



Regards,
- Deven





Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.

Note: This Group is not a Job Searching Group, so please co-operate and dont transfer any kind of job related material across this Group.AnyOne doing so can be banned from the Group
Thanx , Group Co-Ordinators




SPONSORED LINKS
Computer software spy Automotive computer software Medical computer software
Computer telephony software Computer software online training Computer monitoring software


YAHOO! GROUPS LINKS




Sunday, September 25, 2005

[itsdifferent] Ebooks For Java

http://www.dotnetvietnam.org/ebook/
http://www.comp.pucpcaldas.br/users/rene.veloso/ebooks.html
http://www.flazx.com/category2.php
ftp://195.161.102.62/pub/books/
http://stommel.tamu.edu/~baum/programming.html
ftp://137.204.212.13/cad_ebook

http://www.cafeaulait.org/course/week10/index.html -java io notes
ftp://217.218.193.5/software/
ftp://195.135.232.80:21/Books/

http://www.dotnetvietnam.org/ebook/Advanced-HowTo/%28eBook%20pdf%29%
20DEITEL%20-%20Java%20Advanced%20How%20to%20Program%20%28redistilled%
20in%20one%20book%29.pdf

Working
http://aspasia.mm.di.uoa.gr/~rouvas/info/e-books-2/
http://www.mmg.vmei.acad.bg/mmgebooks.html



http://emperorsrage.com/RTFM
http://www.eastasp.com/zh-cn/ebooks/index.aspx
http://argos.observatorio.unal.edu.co/virtual/books/
http://maththinking.com/boat/computerbooks.html
http://stommel.tamu.edu/~baum/programming.html

http://www.et.utt.ro/public/Docs/
http://www.intersoftlb.com/Ebook.aspx
http://www.gayanb.com/

http://www.msri.org/publications/books/

http://campus.en.kku.ac.th/~pongsakorn/download/e-book/

http://www.injunea.demon.co.uk/frames/frm301.htm

http://www.tcfb.com/freetechbooks/

ftp://194.67.191.100/pub/Docs/Books
NEw
http://www.dotnetvietnam.org/ebook/
http://www.itebooks.net/forum/index.jspa


www.eicage.com
http://www.sap-img.com/java/index.htm


Regards,

Ravi








Note: This Group is not a Job Searching Group, so please co-operate and dont transfer any kind of job related material across this Group.AnyOne doing so can be banned from the Group
Thanx , Group Co-Ordinators




SPONSORED LINKS
Computer software spy Automotive computer software Medical computer software
Computer telephony software Computer software online training Computer monitoring software


YAHOO! GROUPS LINKS




[itsdifferent] Satellite Images of Weather

Hello Its-Differents,

Follow this link
http://www.imd.ernet.in/section/satmet/dynamic/insat.htm
to see the Satellite Images of Weather in India in Different
Categories. Its updated daily.



Regards,
- Deven






Note: This Group is not a Job Searching Group, so please co-operate and dont transfer any kind of job related material across this Group.AnyOne doing so can be banned from the Group
Thanx , Group Co-Ordinators




YAHOO! GROUPS LINKS




Thursday, September 22, 2005

[itsdifferent] ViewState Provider - an implementation using Provider Model Design Pattern

PK

PK

Hi Differents, I found following article while searching for "Provider Design Pattern" used in "aspnet forums" and "dotnetnuke" portal. It's very interesting. I've also attached herewith the source code and demo project related to the article. Hope you all will find it usefull .

Introduction

This article focuses on the Provider Model design pattern and describes how it can be used to solve certain problems. To help readers to better understand or appreciate this design pattern, I've chosen view state management as an example to demonstrate the usefulness and practicality of this design pattern. So, in this article, we will first understand what the inherent problems of view state are, I will then explain why Provider Model design pattern is important and how we can leverage it to solve the aforementioned problems.

Background

View State - a love-hate relationship with many ASP.NET developers. Developers love it because it does not require any server state resources and is simple to implement. Page and control state retains automatically across successive posts of the same page instance, which makes the magic of the Web Forms model possible. Furthermore, values in view state are hashed, compressed, and encoded for Unicode implementations, thus representing a higher state of security than hidden fields have. On the other hand, a couple of hot issues surround its use, primarily related to security and performance. For security, because view state is stored in a hidden field on the page. Although view state stores data in a hashed format, the information stored in the hidden field can be seen if the page output source is viewed directly, creating a potential security issue. For performance, because view state is stored in the page itself, storing large values can cause the page to slow down when browsers display or post it.

For those new to ASP.NET, there are a number of good resources for learning more about ASP.NET view state.

Fortunately, the Page class can support alternative storage schemes for view state. The class contains a couple of protected virtual methods that the runtime uses to deserialize or serialize the view state. LoadPageStateFromPersistenceMedium is used to restore the view state at the beginning of the page lifecycle. By contrast, a method named SavePageStateToPersistenceMedium is used to persist the view state just before the page is rendered:

protected virtual void SavePageStateToPersistenceMedium ( object viewState);

protected virtual object LoadPageStateFromPersistenceMedium();

By overriding both methods, you can manipulate the view state at your will. (Note that you cannot override only one method; you have to override both.) The typical solutions are:

  • Compress the view state (Performance)
  • Encrypt the view state (Security)
  • Save view state in a server side file or database table and read/write the view state whenever that page is being processed. (Security and Performance)

Every proposed solution above has its pros and cons. As we all know, there is always a trade-off to choose between security and performance. The problem is how we can design our application in such a way that it can implement these solutions but selectively choose the best for a particular problem domain. For example, you might want to store the view state in a Microsoft SQL Server database for your development tasks and a different one (say Oracle database, which is requested by customer) in production. Choosing the right solution is therefore a matter of matching your needs with respect to how it can solve the problem effectively. Wouldn't it be great if you could implement these solutions on top of a repository that best suits your needs, while at the same time keep the application's architecture, design, and code independent of this choice?

Introducing the Provider Model Design Pattern

Provider Model design pattern derives from a number of widely accepted patterns, and was officially named in the summer of 2002. A "provider" is defined as a pluggable component that extends, or fully replaces, existing system functionality. In other words, the provider model allows you to unplug the default implementation of an API (for example, view state management, session state management, personalization, and so on) and plug your own in. By writing your own provider for a specific system feature that supports the model, you can change the underlying implementation, data formats, and storage medium, without disrupting the application design (keeping the top-level interface intact). More simply put: it allows developers to publish well-documented, easy to understand APIs (Object Model), but at the same time give developers complete control over the internals of what occurs when those APIs are called.

Features implementation that have providers must have a configuration section defined in the web.config (Web applications) or app.config (Windows applications) file. Its purpose is to register the available "providers" but choose one as the default provider. For example:

<!-- View State Provider Configuration -->

<viewstate defaultProvider= "SqlViewStateProvider">

  <add name="SqlViewStateProvider"

    type="System.Web.Configuration.Providers.SqlViewStateProvider,

                                               ViewStateProviders"

    connectionString="SERVER=(local);DATABASE=(Database Name );USERID=sa;PWD=" />

  <add name="CompressionViewStateProvider"

    type="System.Web.Configuration.Providers.CompressionViewStateProvider,

                                                       ViewStateProviders"

    connectionString="" />

  </providers>

</viewstate>

Based on the configuration shown above, the following outlines a few important guidelines to be followed:

defaultProvider

Each feature configuration should specify the default provider, which instructs the system which of the listed providers to use. For example:

<viewstate defaultProvider="SqlViewStateProvider">

Provider-friendly name

When defining a provider within configuration, it is required for the name attribute to be defined. Furthermore, the provider names should follow a pattern to easily distinguish who owns the providers. The suggested pattern is: [Provider Creator][Data Store][Feature]Provider.

<addname="SqlViewStateProvider"

  type="System.Web.Configuration.Providers.SqlViewStateProvider,

                                             ViewStateProviders"

  connectionString="SERVER=(local);DATABASE=(Database Name);USER ID=sa;PWD=" />

Table below calls out some of the common names and casing that should be used for various data stores (where name is [Name][Feature]Provider]. For example, SqlViewStateProvider should be used to name the provider which uses SQL Server as the data store.

NAME

Applies to

Sql

Any provider that uses SQL Server as the data store.

Access

Any provider that uses an Access/Jet database as the data store.

Xml

Any provider that uses an XML file as the data store.

AD

Any provider that uses Active Directory as the data store.

File

Any provider that uses a file as the data store.

Memory

Any provider that uses an in-memory data store.

Provider type

When defining a provider within configuration, it is required for the type attribute to be defined. The type value must be a fully qualified name following the format:

type="[namespace.class], [assembly name], Version=[version],

      Culture=[culture], PublicKeyToken=[public token]"

The strongly typed name is desired, however, it is also legitimate to use the shorter style assembly type name. For example:

type="System.Web.Configuration.Providers.SqlViewStateProvider, ViewStateProviders"

To learn more about the Provider Model design pattern, please read Provider Model Design Pattern and Specification, written by Rob Howard.

ViewState Provider Object Model

The model defines a set of classes to support the view state provider framework. The diagram shown below depicts the ViewState Provider Object Model and its interaction with Page.

  • ViewStateManager - It exposes two static methods, LoadPageState and SaveViewState, which are used by the application (Page, in our context) to load or save its view state, respectively. It contains no business logic; instead it simply forwards these calls to the configured provider, say SqlViewStateProvider. It is the responsibility of the SqlViewStateProvider provider class to contain the implementation of these methods, calling whatever Business Logic Layer (BLL) or Data Access Layer (DAL) to complete the job.

/// <summary>

/// Loads any saved view-state of the current page from virtually any

/// storage medium other than a hidden field

/// </summary>

/// <param name="pControl">System.Web.UI.Page</param>

/// <returns>The saved view state</returns>

public static System.Object LoadPageState(System.Web.UI.Control pControl)

 

/// <summary>

/// Saves any view-state information of the page to virtually any

/// storage medium other than a hidden field

/// </summary>

/// <param name="pControl">System.Web.UI.Page</param>

/// <param name= "viewState">An System.Object in which

///           to store the view-stateinformation</param>

public static void SavePageState (System.Web.UI.Control pControl,

                                                 System.Object viewState)

  • ProviderBase - is used to mark implementers as a provider, and forces the implementation of a required method and property common to all providers.
  • ViewStateProviderBase - it exposes a standard interface (well-known APIs) to the view state management service, and all the custom ViewState providers must inherit from this class. The well-known APIs are:

public abstract System.Object LoadPageState(System.Web.UI.Control pControl);

public abstract void SavePageState(System.Web.UI.Control pControl,

                                                System.Object viewState);

  • ViewStateConfigurationHandler - it interprets and processes the settings defined in XML tags within the <viewstate> section in the Web.config file and returns an appropriate configuration object based on the configuration settings.
  • ViewStateConfiguration - it contains the settings information for all the ViewState providers defined in the Web.config file.

SqlViewStateProvider - The implementation

SqlViewStateProvider provider inherits from ViewStateProviderBase class, it uses SQL Server as the data store to store and retrieve the view state of pages during the page life cycle. The table schema designed for storing the view state is as simple as the diagram shown below:

Field Name

Data Type

Description

vsKey

NVARCHAR(100 )

An unique key to identify the view state of a particular page

vsValue

NTEXT

The view state of a page.

TimeStamp

DATETIME

The last visit timestamp of this view state

Before a page renders its output, the SavePageState method will be called by the framework to save the page's view state. Internally, it checks if a hidden field ( a.k.a. HtmlInputHidden control) named " __vsKey" exists in the page's Controls collection, the hidden field will be created if it doesn't exist. The method's code simply creates an instance of the LosFormatter object and invokes its Serialize() method, serializing the passed-in view state information to the StringWriter writer. Following that, a globally unique identifier (GUID) will be generated and used as the key to save the view state of a particular page to a database table. Last, but not least, this GUID is stored in the hidden field of this page.

When the page posts back, LoadPageState method will be called by the framework to retrieve the saved view state of a particular page. This is accomplished by using the GUID stored in the " __vsKey" hidden field on the last visit to lookup the view state in the database table, and returning the deserialized object via the Derialize() method of LosFormatter.

There is one problem here, each time a user visits a different page, a new record holding that page's view state will be created in the database table. Over time, this will lead to millions of records, which may seriously affect the performance of the lookup process. Some sort of automated task would be needed to periodically clean out the view state records older than a certain date. I leave this as an exercise for the reader.

The diagrams below show the differences before and after using the SqlViewStateProvider provider to store the view state in database instead of storing them in a hidden field named " __VIEWSTATE " of the page.

View State stored in hidden field (Before)

View State stored in database (After)

Using the code

This article ships with two view state providers, available from the link at the top of this article. One of the providers store view state into a SQL Server database table, which is described throughout this article, and the other has the capability of compressing the view state. As noted earlier, if the default functionality of these providers do not meet your needs, you can create your own provider and plug it into the framework.

With ViewState Provider Framework in place, developing a custom view state provider is as easy as the few steps listed below:

1.       Create a new class and derive it from ViewStateProviderBase class. (Remember to follow the naming patterns for provider classes).

2.       Implement the LoadPageState and SavePageState APIs.

3.       Add the new class to the <providers> section in the Web.config file.

4.       Set the defaultProvider attribute's value of <viewstate> section in the web.config file to the newly created provider name.

Conclusion

The provider design pattern allows developers to have a flexible design and a rich, enterprise-level extensibility model. More importantly, you can very easily use one provider for your development tasks, and a different one for the application in production, simply by changing some configuration. Last, but not least, this is an important new design pattern in ASP.NET 2.0, which is extensively used in many common web application features like site membership, role management, personalization, etc. So, start using it in your applications today, and and you'll be ahead of the curve in understanding this design pattern in ASP.NET 2.0 tomorrow.

Reference

Code Project Article : (ViewState Provider - an implementation using Provider Model Design Pattern )   



--
Sudev Gandhi


Note: This Group is not a Job Searching Group, so please co-operate and dont transfer any kind of job related material across this Group.AnyOne doing so can be banned from the Group
Thanx , Group Co-Ordinators




YAHOO! GROUPS LINKS