#2Cookied vs. Cookieless
In ASP.NET 1.x, the browser and ASP.NET server-side environment can exchange the session ID in either of two waysusing a cookie or mangling the requested URL to incorporate the session ID string. Neither approach is free of issues. Not all browsers support cookies and even when the browser does support cookies, the user might have disabled their use. If you opt for a cookieless approach, the session ID shows in the address bar, making it potentially easy for attackers to attempt to hijack a session at least for the duration of the session ID.
|To really benefit from ObjectDataSource, you must have your DAL already in place. ObjectDataSource doesn't break n-tier systems, nor does it transform existing systems into truly n-tier systems.|
In ASP.NET 2.0, the cookieless approach is also possible for form-based authentication. Obviously, using cookieless authentication is recommended in very particular cases. The canonical example is an international security-sensitive application (i.e., an international Internet banking application) running in a country where cookies are prohibited by law. When you opt for cookieless authentication, make sure you also work on a secure channel (HTTPS) and with sliding expiration to mitigate the risk of replay attacks.
As mentioned, with cookieless sessions the risk is a session hijacking attack. The attack is not necessarily harmful per se. Its effects mostly depend on what the attacker finds stored in the session state. If no sensitive data is cached in the session state, the risk of reporting damages is low.
The bottom line is that you should opt for cookied clients unless strict and precise requirements force you to set up a cookieless solution.
As a further note, consider that in ASP.NET 2.0 cookies are also used to cache role information for performance gains. When role management is enabled and a user connects, role information is retrieved, placed in a (configurable) cookie and attached to the response for next time. If cookies are disabled, role information is read from the data source on each and every request.
The Holy Grail of Web development is finding a magic combination of technologies to build applications that render and work the same whatever browser or device is used.
Some developers prefer to create two distinct applications for uplevel and downlevel browsers. Other developers tend to use CSS styles to the extent that it is possible to differentiate the rendered markup on a per-browser basis. Yet another group of Web developers have placed their hopes in a new ASP.NET 2.0 technology named adaptive rendering
Adaptive rendering is the process by means of which server controls generate markup specifically crafted for a particular browser. An external component-the control adapter-takes care of generating the markup in lieu of the control itself. When it is about to render, each control figures out its own adapter and delegates the task to it.
The adapter for a control is resolved by looking at the browser capabilities, as configured in the .browser
text files that accompany the ASP.NET 2.0 installation. You look for these files under the following path:
If the browser record specifies an adapter class for the control, that class is instantiated and used. Otherwise, the adapter for the control is an instance of a generic adapter that simply generates the markup for a control by calling the rendering methods on the control itself.
Writing an adapter component is not a trivial task because it requires that you understand the events in the lifecycle of both pages and controls to know where to apply your device-specific adaptation. In ASP.NET 2.0, a simpler form of adaptive rendering consists of declaratively assigning a browser-specific value to some control properties. Clearly, adaptive rendering and browser-sensitive rendering are two substantially different things. The former lets you adapt the behavior of the control to the browser. The latter is simply a declarative way of deciding which value to assign to individual properties based on the browser's name. Here's an example.
<asp:TextBox ID="TextBox1" runat="server"
property of the TextBox control will limit the buffer of the text box to ten characters if the page is viewed through Internet Explorer. If Firefox (or any Mozilla-powered browser) is used, the maximum length is seven, or eight when a Netscape browser is used. If another browser is used, the value of the unprefixed MaxLength
attribute is used. All properties you can insert in a tag declaration can be flagged with a browser ID. Each supported browser has a unique ID. As in preceding code, ie is for Internet Explorer whereas mozilla
is for Firefox and netscape6to9
is for versions of Netscape browsers ranging from 6.x to future versions. Check out the documentation for browser capabilities to find out which is the ID of a particular browser or device.
Browser-specific filtering is also supported for master pages. Much like a PowerPoint master slide, a master page is the ASP.NET page your displayed page is based upon. If you're employing master pages to build pages in your site, you can have the ASP.NET runtime switch the master on the fly for you as the user connects via a different browser.
You design the master to address the specific features of the browser. In doing so, you create multiple versions of the same master, each targeting a different type of browser. How do you associate masters and browsers?
In the content page, that is the page your users display, you define multiple bindings using the MasterPageFile
attribute. Each binding is prefixed with the identifier of the browser. For example, suppose you want to provide ad hoc support for Internet Explorer and use a generic master for any other browsers that users employ to visit the site. You use the following syntax.
<%@ Page MasterPageFile="Base.master"
ASP.NET will use the ieBase.master
file for Internet Explorer and nsBase.master
for Netscape browsers from version 6.x on. In any other case, ASP.NET will use a device-independent master (Base.master
). When the page runs, the ASP.NET runtime automatically determines which browser or device the user is using and selects the corresponding master page, as shown in Figure 1
|Figure 1: The page may change it's structure and logic entirely to reflect the capabilities of the underlying device.|
Table 1 shows the ID of the most common desktop browsers and mobile devices such as cellular phones and personal digital assistants (PDAs).
Table 1: ID of most common browsers and mobile devices.
Any version of Internet Explorer
Netscape Navigator 3.x
Netscape Communicator 4.x
Any version of Netscape higher than 6.0
Firefox and other Mozilla-powered browsers
Pocket Internet Explorer
It is important to note that if you use device-specific masters, you must also indicate a device-independent master to stay on the safe side and avoid anomalies in case a user uses a non-supported browser.