Introduction This will be
the first of a number of posts on ASP.NET extensibility. At this moment I don’t know exactly how many will be and I only know a couple of subjects that I want to talk about, so more will come in
the next days. I have
the sensation that
the providers offered by ASP.NET are not widely know, although everyone uses, for example, sessions, they may not be aware of
the extensibility points that Microsoft included. This post won’t go into details of how to configure and extend each of
the providers, but will hopefully give some pointers on that direction. Canonical These are
the most widely known and used providers, coming from ASP.NET 1, chances are, you have used them already. Good support for invoking client side, either from a .NET application or from JavaScript. Lots of server-side controls use them, such as
the Login control for example. Membership
The Membership provider is responsible for managing registered users, including creating new ones, authenticating them, changing passwords, etc. ASP.NET comes with two implementations, one that uses a SQL Server database and another that uses
the Active Directory.
The base class is Membership and new providers are registered on
the membership section on
the Web.config file, as well as parameters for specifying minimum password lengths, complexities, maximum age, etc. One reason for creating a custom provider would be, for example, storing membership information in a different database engine. 1: <membership defaultProvider="MyProvider">
2: <providers>
3: <add name="MyProvider" type="MyClass, MyAssembly"/>
4: </providers>
5: </membership>
Role
The Role provider assigns roles to authenticated users.
The base class is Role and there are three out of
the box implementations: XML-based, SQL Server and Windows-based. Also registered on Web.config through
the roleManager section, where you can also say if your roles should be cached on a cookie. If you want your roles to come from a different place, implement a custom provider.
1: <roleManager defaultProvider="MyProvider">
2: <providers>
3: <add name="MyProvider" type="MyClass, MyAssembly" />
4: </providers>
5: </roleManager>
Profile
The Profile provider allows defining a set of properties that will be tied and made available to authenticated or even anonymous ones, which must be tracked by using anonymous authentication.
The base class is Profile and
the only included implementation stores these settings in a SQL Server database. Configured through profile section, where you also specify
the properties to make available, a custom provider would allow storing these properties in different locations.
1: <profile defaultProvider="MyProvider">
2: <providers>
3: <add name="MyProvider" type="MyClass, MyAssembly"/>
4: </providers>
5: </profile>
Basic
OK, I didn’t know what to call these, so Basic is probably as good as a name as anything else. Not supported client-side (doesn’t even make sense).
Session
The Session provider allows storing data tied to
the current “session”, which is normally created when a user first accesses
the site, even when it is not yet authenticated, and remains all
the way.
The base class and only included implementation is SessionStateStoreProviderBase and it is capable of storing data in one of three locations:
In
the process memory (default, not suitable for web farms or increased reliability);
A SQL Server database (best for reliability and clustering);
The ASP.NET State Service, which is a Windows Service that is installed with
the .NET Framework (ok for clustering).
The configuration is made through
the sessionState section. By adding a custom Session provider, you can store
the data in different locations – think for example of a distributed cache.
1: <sessionState customProvider=”MyProvider”>
2: <providers>
3: <add name=”MyProvider” type=”MyClass, MyAssembly” />
4: </providers>
5: </sessionState>
Resource
A not so known provider, allows you to change
the origin of localized resource elements. By default, these come from RESX files and are used whenever you use
the Resources expression builder or
the GetGlobalResourceObject and GetLocalResourceObject methods, but if you implement a custom provider, you can have these elements come from some place else, such as a database.
The base class is ResourceProviderFactory and there’s only one internal implementation which uses these RESX files. Configuration is through
the globalization section.
1: <globalization resourceProviderFactoryType="MyClass, MyAssembly" />
Health Monitoring
Health Monitoring is also probably not so well known, and actually not a good name for it. First, in order to understand what it does, you have to know that ASP.NET fires “events” at specific times and when specific things happen, such as when logging in, an exception is raised. These are not user interface events and you can create your own and
fire them, nothing will happen, but
the Health Monitoring provider will detect it. You can configure it to do things when certain conditions are met, such as a number of events being fired in a certain amount of time. You define these rules and route them to a specific provider, which must inherit from WebEventProvider. Out of
the box implementations include sending mails, logging to a SQL Server database, writing to
the Windows Event Log, Windows Management Instrumentation,
the IIS 7 Trace infrastructure or
the debugger Trace. Its configuration is achieved by
the healthMonitoring section and a reason for implementing a custom provider would be, for example, locking down a web application in
the event of a significant number of failed login attempts occurring in a small period of time.
1: <healthMonitoring>
2: <providers>
3: <add name="MyProvider" type="MyClass, MyAssembly"/>
4: </providers>
5: </healthMonitoring>
Sitemap
The Sitemap provider allows defining
the site’s navigation structure and associated required permissions for each node, in a tree-like fashion. Usually this is statically defined, and
the included provider allows it, by supplying this structure in a Web.sitemap XML file.
The base class is SiteMapProvider and you can extend it in order to supply you own source for
the site’s structure, which may even be dynamic. Its configuration must be done through
the siteMap section.
1: <siteMap defaultProvider="MyProvider">
2: <providers><add name="MyProvider" type="MyClass, MyAssembly" />
3: </providers>
4: </siteMap>
Web Part Personalization
Web Parts are better known by SharePoint users, but since ASP.NET 2.0 they are included in
the core Framework. Web Parts are server-side controls that offer certain possibilities of configuration by clients visiting
the page where they are located.
The infrastructure handles this configuration per user or globally for all users and this provider is responsible for just that.
The base class is PersonalizationProvider and
the only included implementation stores settings on SQL Server. Add new providers through
the personalization section.
1: <webParts>
2: <personalization defaultProvider="MyProvider">
3: <providers>
4: <add name="MyProvider" type="MyClass, MyAssembly"/>
5: </providers>
6: </personalization>
7: </webParts>
Build
The Build provider is responsible for compiling whatever files are present on your web folder. There’s a base class, BuildProvider, and, as can be expected, internal implementations for building pages (ASPX), master pages (Master), user web controls (ASCX), handlers (ASHX), themes (Skin), XML Schemas (XSD), web services (ASMX, SVC), resources (RESX), browser capabilities files (Browser) and so on. You would write a build provider if you wanted to generate code from any kind of non-code file so that you have strong typing at development time. Configuration goes on
the buildProviders section and it is per extension.
1: <buildProviders>
2: <add extension=".ext" type="MyClass, MyAssembly” />
3: </buildProviders>
New in ASP.NET 4
Not exactly new since they exist since 2010, but in ASP.NET terms, still new.
Output Cache
The Output Cache for ASPX pages and ASCX user controls is now extensible, through
the Output Cache provider, which means you can implement a custom mechanism for storing and retrieving cached data, for example, in a distributed fashion.
The base class is OutputCacheProvider and
the only implementation is private. Configuration goes on
the outputCache section and on each page and web user control you can choose
the provider you want to use.
1: <caching>
2: <outputCache defaultProvider="MyProvider">
3: <providers>
4: <add name="MyProvider" type="MyClass, MyAssembly"/>
5: </providers>
6: </outputCache>
7: </caching>
Request Validation
A big change introduced in ASP.NET 4 (and refined in 4.5, by
the way) is
the introduction of extensible request validation, by means of a Request Validation provider. This means we are not limited to either enabling or disabling event validation for all pages or for a specific page, but we now have fine control over each of
the elements of
the request, including cookies, headers, query string and form values.
The base provider class is RequestValidator and
the configuration goes on
the httpRuntime section.
1: <httpRuntime requestValidationType="MyClass, MyAssembly" />
Browser Capabilities
The Browser Capabilities provider is new in ASP.NET 4, although
the concept exists from ASP.NET 2.
The idea is to map a browser brand and version to its supported capabilities, such as JavaScript version, Flash support, ActiveX support, and so on. Previously, this was all hardcoded in .Browser files located in %WINDIR%\Microsoft.NET\Framework(64)\vXXXXX\Config\Browsers, but now you can have a class inherit from HttpCapabilitiesProvider and implement your own mechanism. Register in on
the browserCaps section.
1: <browserCaps provider="MyClass, MyAssembly" />
Encoder
The Encoder provider is responsible for encoding every string that is sent to
the browser on a page or header. This includes for example converting special characters for their standard codes and is implemented by
the base class HttpEncoder. Another implementation takes care of Anti Cross Site Scripting (XSS) attacks. Build your own by inheriting from one of these classes if you want to add some additional processing to these strings.
The configuration will go on
the httpRuntime section.
1: <httpRuntime encoderType="MyClass, MyAssembly" />
Conclusion
That’s about it for ASP.NET providers. It was by no means a thorough description, but I hope I managed to raise your interest on this subject. There are lots of pointers on
the Internet, so I only included direct references to
the Framework classes and configuration sections.
Stay tuned for more extensibility!
