January 23, 2016

ASP.Net - Understanding Navigation Controls SiteMapPath, Menu, TreeView

1. Introduction

The "Navigation Controls" are useful for maintaining the page hierarchy as well as the page navigation. There are three navigation controls that can be used in ASP.Net 2.0 and above. These controls are:

  1. SiteMapPath
  2. Menu
  3. TreeView

The above controls are grouped under Navigation” in your toolbox and this is shown in the below picture:

Fig 1. Navigation control in ToolBox
Fig 1. Navigation control in ToolBox

All three controls operate on the Web site map and the controls Menu and tree view should be tied with the Datasource. In this article, we will see creating and using these controls. The example application from Article Number 15 in ASP.net section of this site is used to demonstrate the Navigation controls.

2. About the Example

The screenshot below shows the example:

  Fig 2. About the Example
Fig 2. About the Example

The item marked as one shows the usage of the "Menu Navigation" control. The menu can be laid horizontal or vertical. In our example the menu has the horizontal orientation. Item marked as 2 in the example shows the "TreeView Navigation Control" and it shows the Navigational link as well as the hierarchical Relationship between the links. If you see here, the links are grouped under the country names. The items marked as 3 shows the usage of the "SiteMapPath Navigation Control". The path navigation control is useful to know which page we are viewing in a big site and path to that page from the top level page. All these control together demonstrates the usage of the navigational control on ASP.Net 2.0 and above.

3. Making the Application

To create the application:
1) Download the MasterPage Example from this website. The Asp.Net section, article Number 15 has the link to that article and downloadable example.

2) Once you downloaded it, add four new .aspx pages called Home, India, USA and Egypt and some description for each pages. While adding the pages make sure to specify the MasterPage.Master as the Master Page.

3) Once all four pages are added, it is time to add the Web.SiteMap to the Project. This can be done by invoking “Add New Item” context menu for the project. The web.sitemap file is used to specify the hierarchical relationship between the pages. Now the below screenshot all the newly added files to the project:

Fig 3. Newly Added Files
Fig 3. Newly Added Files

4) Modify the web.sitemap to specify the hierarchy of web pages. In our example, the file groups the pages under three categories named 1) India 2) USA and 3) Egypt and the content of the web.SiteMap is given below:

Fig 4. Content of Web.SiteMap
Fig 4. Content of Web.SiteMap
Here, the root node is “SiteMap” (Marked as 1) and it has a “SiteMapNode” for the home page (Marked as 2). These two nodes are standard for almost all the ASP.Net web sites. After these nodes the hierarchy begins and varies from site to site & based on how the site was organized. In our example, you can see the web pages (Marked as 4) grouped under the category pages (Marked as 3).

Each SiteMapNode should have two important attributes defined in it. The URL attribute specifies the webpage name with extension and Title is used to specify the text that can be used by the navigation control (Displays these title as hyper links). Below video shows adding the pages are sitemap:

Video 1: Adding Webpages and SiteMap

4. Adding Navigation Controls

Once the site map for the web application is specified we can start using the navigational control. In our Example, first the “SiteMapPath control is added to the footer portion of the master Page. The design view is shown below:

Fig 5. Location SiteMapPath Control in the Form
Fig 5. Location SiteMapPath Control in the Form

After adding this control, “SiteMapDataSource control” is added to the web page. The control is added to the master page. However, the location of the control is not important as this is not going to be rendered on the web page. This is shown below:

Fig 6. Adding SiteMapDataSource to the Form
Fig 6. Adding SiteMapDataSource to the Form
Once this SiteMapDataSource control is added to the project, the other two navigational controls can be added to the project. The Menu navigation control is added to the header portion of the master page and the Treeview Navigation control is added to the left margin of the master page. These control need to specify the SiteMapDataSource through it properties. No coding is required as these two control queries the SiteMapDatasource to know the hierarchical relationship. Even though we don’t specify the linkage between DataSource and Web.SiteMap, the relationship will be automatically established once the control is added to the form. The video below shows adding these controls and examining how these Navigation controls work.

Video 2: Using the Navigation Controls

In the above video, you saw styles set for the Menu and TreeView and that has no effect. Since both controls are set with the formatting, the style won’t come into picture. Once you remove formatting (Through AutoFormat quicklink) these styles will be reflected on the controls.

Listing 1.1

 <?xml version="1.0" encoding="utf-8" ?>
<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" >
 <siteMapNode url="Home.aspx" title="Home Page"  
  description="Home Page for Navigation Control Demo">
 <siteMapNode url="India.aspx" title="India"  
    description="Country - India">
 <siteMapNode url="HarmandirSahib.aspx" title="HarmandirSahib" 
 description ="Harmandir Sahib"> </siteMapNode>
 <siteMapNode url="AjantaCave.aspx" title="AjantaCave" 
 description ="Ajanta Caves"> </siteMapNode>
 <siteMapNode url="TajMahal.aspx" title="TajMahal" 
 description ="TajMahal"> </siteMapNode>
 <siteMapNode url="USA.aspx" title="United States of America"  
    description="Country - USA">
 <siteMapNode url="NiagaraFalls.aspx" title="NiagaraFalls" 
 description ="Niagara Falls"> </siteMapNode>
 <siteMapNode url="Yellowstone.aspx" title="Yellowstone" 
 description ="Yellow stone"> </siteMapNode>
 <siteMapNode url="LasVegasStrip.aspx" title="LasVegasStrip" 
 description ="LasVegas Strip"> </siteMapNode>
 <siteMapNode url="Egypt.aspx" title="Egypt"  
    description="Country - Egypt">
 <siteMapNode url="AbuSimbel.aspx" title="AbuSimbel" 
 description ="AbuSimbel"> </siteMapNode>
 <siteMapNode url="GizaNecropolis.aspx" title="GizaNecropolis" 
 description ="Giza Necropolis"> </siteMapNode>
 <siteMapNode url="RiverNileCruise.aspx" title="RiverNileCruise" 
 description ="River Nil eCruise"> </siteMapNode>
Source Code: Download

January 10, 2016

C# - Code Access Security and Security Action Examples

1. Introduction

In dot net framework, security to the application is applied through the dot net supplied Security Framework. The topic of interest is shortly called as CAS (Code Access Security)”. The code access security at top most level can be seen through the “Dot net configuration” utility which can be accessed through the administrative tools as shown in the below screenshot:

Fig 1. Accessing DotNet Configuration tools
Fig 1. Accessing DotNet Configuration tools

In this article, we are going to understand how Code Access Security can be used at the assembly level.

2. CAS - Security Zones

The "security zone" identifies the location from which the application is running. Say; for example, the dotnet application that runs through the internet is seen as internet zone application. So based on the locations, the zones are identified and appropriate set of securities are applied to it. The below-given video shows the security zone on a system through dot net configuration utility.

Video 1: Examining the Permission set for a Zone

From the above video, we got an idea of how security can be applied based on the zone in which the application is running. For example, we saw only username environment variable can be read by any dotnet application that runs through the local intranet. These dot not permission set cannot be confused with the windows security. Windows Security (Operates on Username and role groups) takes the first precedence and then dot net security applied on top of it. If user logged in as a guest user, then they have only limited access even though the application runs on “Trusted Zone” (A Zone that has no security limitation from dot net security point of view).

When you develop an application, based on the location in which it is going to run, the permission sets are assigned to it.  An assembly can elevate permission coming from the zone.

3. About the Example

 Have a look at the below screenshot:

Fig 2. About the Example
Fig 2. About the Example

Above given example is used to understand the code access security applied to an assembly. The buttons (Marked as 1 and 2) are used to read the System environment variables called SecTest and UserName. UserName is a built-in environment variable and SecTest is created for checking the code access security. The textbox (marked as 3) is used to display the system environment variable.

4. Code to Read Environment variables

1) System environment variables are secured information and we are reading those through both the button click event handler. First, we will include a required namespace to catch any security exception. The Code is below:

//Sample 01: Name Space inclusion
using System.Security;

2) The “GetEnvironmentVariable” function is called in both button event handlers to retrieve the environment variable values. And these values are displayed in the textbox txtVal.  Note the usage of the SecurityException” in the catch block and this is used to get information related to any security failures (That is going to happen soon when we are progressing through this article).

//Sample 02a: Read Environment variable SecTest
private void btnRead_Click(object sender, EventArgs e)
        txtVal.Text = Environment.GetEnvironmentVariable("SecTest");
    catch (SecurityException Ex)
        MessageBox.Show("Security Exception Caught: " + Ex.Message);

//Sample 02b: Read Environment variable UserName
private void btnWrite_Click(object sender, EventArgs e)
        txtVal.Text = Environment.GetEnvironmentVariable("UserName");
    catch (SecurityException Ex)
        MessageBox.Show("Security Exception Caught: " + Ex.Message);

That is all the coding here. You build the solution and run to check how the sample application is working. The below video creates the SecTest environment variable and runs the application.

Video 2: Create SecTest Environment variable and Run Exe

5. Security Actions for Assembly

Dot net framework 2.0 and beyond provides three kinds of security actions for any given security say Accessing Registry or Reading a file from secured location etc. These three security actions are:

  1. RequestMinimum
  2. RequestRefuse
  3. RequestOptional

In this section, we will examine each security actions one by one with the application tested in the previous sections. Remember the fact that we tested the Application in trusted mode. To check the above security action we should test application in more secure environment say; "Internet Zone" or "Intranet Zone". I will explain how we can do that shortly. Each of the above security action is applied to assembly using the attributes defined for Permission Sets. Now we will examine these security actions one by one for the "Environment Permission" set.

6. "RequestMinimum Security" action

This security action checks for the security before loading the assembly into the memory. When the checked security is not granted for the assembly, the assembly load is prohibited. Say; for example, let us say, assembly don’t have permission to read environment variable “Username” and when we claim to read that environment variable with request minimum action, the assembly load cancelled with an error.

The below screen shot shows the security attribute with Request Minimum Action:
Setting security attribute to Assembly
Fig 3. Setting security attribute to Assembly
The "Assembly" (Marked as 1) says that the attribute is an assembly level attribute. The "EnvironmentPermission" (Marked as 2) class in the attribute is used to link the "Security action" (Marked as 3) and the resource (Marked as 4) in which it can be applied. Each "PermissionSet" has the associated permission class.  Once we place above attribute in the top level (Even before the NameSpace), during the assembly load, the permission to read the system environment variable username is ensured. The below video shows checking our sample application with this attribute:

Video 3: Checking RequestMinimum Security action

7. "RequestOptional Security" action

The “RequestOptional Security" action is used mark a specified security as optional. For Example; if I mark Reading User Name Environment as optional, the assembly is loaded whether the assembly has permission or not. When assembly do not have permission, the error is thrown at runtime while an attempt is made to read that environment variable.

//Sample 04:Place Assembly level security actions here
[assembly: EnvironmentPermission(SecurityAction.RequestOptional, Read="SecTest")]

In the above code, Read Access to the SecTest Environment variable is made optional. This will allow the assembly to load even through the zone has not permission. In that case, an exception is thrown at runtime when an attempt is made to read the SecTest.

Also, note that the RequestOptional security sets RequestRefuse security action for all other permission sets. The video.3 shows how the optional request for SecTest environment variable is set to successfully load the assembly.

Video 4: Checking RequestOptional Security action

8. "RequestRefuse Security" action

The “RequestRefuse” security action is used reject a specified security even though the zone has granted access for it. Remember how the UI permission (In the previous video) throws the error even the zone has access to it. OK, we will examine how request refuse works with the below video.

Video 5: Checking RequestRefuse Security Action

Source Code: Download

Like this site? Tell it to your Friend :)