Web developer follows the approach described in the article when he/she wants to make some pages accessible to the public. In this case Web developer should implement the solution described in the article How to restrict access to all application pages in C# or in the article How to restrict access to all application pages in VB.NET and then he/she has to modify the contents of the web.config file to list the pages that allow public access and those that require authentication as:
- Change the <deny> child element of the <authorization> element to <deny users=”*”/> and delete the <allow> child element to deny access to all users.
- Add a <location> element to the configuration level for each application page to specify whether it is available to the public or only to authenticated users.
Access to the individual pages in the application is controlled by providing a <location> element for each page. For pages with public access, the <location> element should be set up as follows:
<location path=”PublicApplicationPage.aspx“>
<system.web>
<authorization>
<allow users=”*”/>
</authorization>
</system.web>
</location>
The path attribute of the <location> element specifies the page that this <location> element applies to. The <authorization> element defines the access to the page defined in the path attribute. For public access, the <authorization> should be set to allow all users (users=”*”).
To limit access to individual pages, a <location> element is provided for each of the restricted pages, as follows:
<location path=”StartPage.aspx”>
<system.web>
<authorization>
<deny users=”?” /> <!— Deny anonymous (unauthenticated) users —>
<allow users=”*”/> <!— Allow all authenticated users —>
</authorization>
</system.web>
</location>
The primary difference is the inclusion of two <authorization> child elements. The <deny> element denies access to anonymous (unauthenticated) users. The <allow> element allows access to all authenticated users. In the code two special identifies are used: ? and *, where ? refers to the anonymous identity, and * refers to all identities.
One of the disadvantages of using a <location> element for each page Web developer wishes to make accessible to authenticated users is the maintenance of all the page names in the <location> elements. Web developer can structure the web application, by placing public pages and private pages in separate folders, and then he/she can provide one <location> element for the public folder and a second one for the private pages:
<!–
***************************************************************************
The following location element provides public access to all pages in the PublicPages folder.
***************************************************************************
–>
<location path=”PublicPages”>
<system.web>
<authorization>
<allow users=”*”/>
</authorization>
</system.web>
</location>
<!–
***************************************************************************
The following location element restricts access to all pages in the PrivatePages folder.
***************************************************************************
–>
<location path=”PrivatePages”>
<system.web>
<authorization>
<deny users=”?” /> <!— Deny anonymous (unauthenticated) users —>
<allow users=”*”/> <!— Allow all authenticated users —>
</authorization>
</system.web>
</location>
Using <location> elements to define separate folders for public and private pages is analogous to their use to set authorization requirements for individual pages, except the path attribute is set to a relative path to an applicable folder rather than to a specific .aspx page.