Composite Web Clients

Today I read about Web Client Software Factory (WCSF) which talks about the challenges faced in the web application development and how to follow proven patterns and practices to overcome these in order to produce reusable loosely coupled code, which can be unit tested. In the series of few posts I will like to add some key points which I have picked about WCSF.  First lets talk about composite web clients. Because the whole WCSF is based to promote composite web clients, lets talk about it a bit more.

A composite Web client application is a Web application that is composed of a number of discrete and independent pieces. These pieces are integrated together within a Web server environment; they are presented to the user in a Web browser as a fully coherent Web client solution. The Composite pattern is a popular and recurring theme because it provides a flexible and scalable architecture that provides several key benefits, including the following:

  1. It allows a higher degree of separation between application infrastructure and business logic.
  2. It allows more independent development of the individual business logic components themselves.
  3. It provides solution agility because business logic components can be flexibly combined to quickly yield a specific solution.
  4. It promotes code re-use because it allows business logic components and the application infrastructure to be re-used across multiple solutions.
  5. It provides an excellent architecture for the front-end integration of line-of-business systems or service-oriented systems into a task-oriented user experience.

ASP.Net 2.0 and composite web clients:- A Web client using the Composite pattern generally involves a shell, which provides the overall user interface structure. For a Web client, the shell is a master page. You can use ASP.NET master pages to create a consistent layout for the pages in your application. A single master page defines the look and feel and standard behavior that you want for all the pages (or a group of pages) in your application. You can then create individual content pages that contain the content you want to display. When users request the content pages, they merge with the master page to produce output that combines the layout of the master page with the content from the content page. Modules contain functionally discrete pieces, but they integrate with the user interface, communicate with the shell, and communicate with each other. The shell provides access to services required by modules throughout the application. This means that the modules can leverage these capabilities instead of having to implement them themselves. This allows a solution to be developed much more quickly because the Web client infrastructure is already in place—the modules can focus on the business logic and their piece of the overall solution instead of focusing on the basic foundation that is required to provide the necessary Web client capabilities.

refer CodePlex for more.

This posting is provided “AS IS” with no warranties, and confers no rights.


Securing Cookies in Web Application

It is important to secure the cookies that are used by the web application. While it is a bad idea to save sensitive information in a cookie anyway, sometimes it becomes almost essential to use cookies. There are three properties that can be set on HttpCookie objects which will make the cookie secured.  We will discuss them: 

  1. fooCookie.HttpOnly = true; – Specifies whether a cookie is accessible by client-side script. By marking the Cookies with HttpOnly clientside scripts are unable to access them.
  2. fooCookie.Secure = true; – Specifies whether to transmit the cookie using Secure Sockets Layer (SSL)–that is, over HTTPS only. Any area of a website or web application that contains sensitive information or access to privileged functionality requires that
    all cookies are sent via SSL during a SSL session. If a cookie is marked secure, it will only be transmitted if the communications channel with the host is a secure one. This means that secure cookies will only be sent to HTTPS (HTTP over SSL) servers. If secure is not specified, a cookie may be captured by an attacker carrying out a man-in-the-middle attack, allowing session
    hijacking to occur.
  3. fooCookie.Path = Context.Request.ApplicationPath; – Sets the virtual path to transmit with the current cookie. It is a good practice to set the cookies path to application root.

This posting is provided “AS IS” with no warranties, and confers no rights.

Posted in .net, asp .net, web. Tags: . 1 Comment »

Edit project files from VS

Here is a cool trick I learnt recently. Most of the time if I need to edit the project files (csproj or vbproj)  manually I open them in notepad or any other text editor.

But what if one needs to edit a project file, while it is loaded in visual studio.

For standard .csproj and .vbproj files do the following:

  • Open the project in Visual Studio 2005
  • Right-click on the project in Solution Explorer and select Unload Project
  • Right-click on the project in Solution Explorer and select Edit <project file>
  • Once you are done editing Save and close the project file
  • Right-click on the project in Solution Explorer and select Reload Project

The benefit of this way is that you don’t need to close the solution and exit visual studio. As well since you are editing it from Visual Studio you get the syntax highlighting and nicely aligned xml file.

AssemblyVersion & AssemblyFileVersion

While both AssemblyVersion and AssemblyFileVersion attributes are used to version the assemblies, but you can use them to differentiate between the assembly version deployed on Live environment as against on your local development machines.

Both are present in the AssemblyInfo.cs (or .vb) class

[assembly: AssemblyVersion(“”)][assembly: AssemblyFileVersion(“”)]The AssemblyVersion is what other assemblies that reference your namespace will look at. If that number changes, then the referencing assembly will throw an exception. By default is AssemblyFileVersion is not set then it will be same as the AssemblyVersion. Increment it every time a new version of the assembly is deployed.

It is important to note that AssemblyVersion can be set to autoincrement by using *. example:

[assembly: AssemblyVersion(“1.0.0.*”)] will increment the revision number each time the assembly is built.

I am still not convinced by myself if one will ever need to use two of these seperately. If someone can help me, that will be great.