Handling 401 (Access Denied) errors with ASP.NET

Handling 401 (Access Denied) errors are easy to handle in ASP.NET. The reason is that it is a simple configuration that can be made at the IIS level, not at the code level.

While it is true you can get to the Request.Status or Request.StatusCode in your Global.asax file. You can also do a Server.Transfer() or Response.Redirect() on your master page. There are lots of ways to handle this. The problem is that if you want to distinguish between 401.1, 401.2, 401.3… 401.7 it is best to use the solution presented here.

Here is a good list of the HTTP Codes. For reference, here is what it says about the 401 codes.

401 - Access denied. IIS defines several different 401 errors that indicate a more specific cause of the error. These specific error codes are displayed in the browser but are not displayed in the IIS log:
401.1 - Logon failed.
401.2 - Logon failed due to server configuration.
401.3 - Unauthorized due to ACL on resource.
401.4 - Authorization failed by filter.
401.5 - Authorization failed by ISAPI/CGI application.
401.7 – Access denied by URL authorization policy on the Web server.

I recommend replacing 401.1 and 401.2 standard files in IIS with your own. This will cause the standard 401.1. and 401.2 pages to not be displayed and instead your custom files be shown to the end user. 401.1 is what the user will get if they click the Cancel button on the authentication prompt. 401.2 is what they will get if they actually have bad username and password for three attempts.

The first thing we need to do is create a new web site or create a virtual directory inside a web site. This is the location were we will save our custom access denied files. In theory you could do this in the same location as your web application, but I like to use the same 401.1 and 401.2 files for all my applications. That way there is less configuration when I deploy a new application to a server.

1. Make sure Anonymous is enabled under the Directory Security tab.
2. Navigate in Windows Explorer to the directory and files.
3. Right-click the directory, choose Properties.
4. Go to the Security tab and make sure the IIS_WPG group has Read permissions.

To setup your web site (your ASP.NET application) just do the following:

1. Open up Internet Information Services (IIS) Manager.
2. Expand Web Sites in the tree view
3. Right-click on your website or virtual directory and choose the Properties menu item.
4. Go to the Custom Errors tab as shown below.
   

   

5. Click on 401.1 line and click the Edit… button.
6. You will see a window titled Edit Custom Error Properties.
7. Select File from Message type drop down list.
8. Use the Browse… button to select the access denied page that resides in the anonymous web site we set up.
9. The window should look something like this.
   
   
10. Do the same thing for the 401.2 item.

Now when a user would normally get the generic 401.1 or 401.2 pages, they will now get your custom pages.

Search Connectors

Microsoft Enterprise Search Products / Solutions

• Search Server 2008 Express
• Search Server 2008
• Office SharePoint Server 2007 (MOSS)
• FAST ESP

Search Connectors (more info)

• Indexed Search Connectors – allows  to index the contents of a target system. This is done by creating an internal representation of the content that can be used to return search results quickly. This is the most powerful connector to a target system. There are two main categories of Indexed Search Connectors.
  • Microsoft Indexing Connectors - There are many available for free for Download from Microsoft, and additional from MS Partners.
    • Protocol Handlers (more info) - for unstructured data sources.  Opens content sources in their native protocols and exploses documents and other item to be filtered. Implemented as COM objecs that implement the ISearchProtocol interface. The crawl process works much like the Google Mini. It requires a starting url, and crawls the pages using links on pages. The url determines what kind of protocol handler will be used to crawl a url.
    • Business Data Catalog Application Definition Files – for structured data sources
  • FAST Indexing Connectors – for both structured and unstructured data sources. They are available for purchase for any FAST ESP system.
• Federated Search Connectors (more info) – The actual search is “out-sourced” to another search engine. Content is not crawled in this approach. Instead, you are enabled to display search results for additional content that is not crawled by your search server. With federation, the query can be performed over the local content index, or it can be forwarded to an external content repository where it is processed by that repository's search engine. The repository's search engine then returns the results to the search server. The search server formats and renders the results from the external repository within the same search results page as the results from the search server's own content index. If search engine does not adhere to standard interfaces, a custom interface may need to be developed that does adhere to a standard interface. Triggers can be used to determine when a search returns federated results. For example, keywords, always, and pattern matching. Anonymous, Common, and Per-User credentials are supported. These credentials can be passed by most any common protocol including Basic, Digest, NTLM, Forms, Cookies, and Kerberos. There is an API to create custom federated search Web Parts. This applies for MOSS as well. Lots of docs via SharePoint docs.
• iFilters – allow indexing of a wide variety of documents and file types using a common interface across Search Server 2008, Office SharePoint Server 2007, Windows SharePoint Servies 3, Windows Desktop Search, Windows Vista, and SQL Server. Opens documents and other content source items in their native formats and filters these into chunks of text and properties. It can be part of the protocol handler component or it can be a separate component.

For a more in-depth review of whether to use a Federated or Crawled approach, click here.

How to fix a broken “Go to Calendar” link on a SharePoint Meeting Workspace

Here the scenario, you have a SharePoint Meeting Workspace. Near the top left of the page you will see a Go to Calendar link. You click the link and get a 404 error.

What this typically means is that there was a calendar that used to exist that does NOT exist anymore, the location has changed, or in general the url has been changed in some way.

Your first step is to figure out if the calendar that it is looking for still exists or not. You can look at the url that the Go to Calendar link points to, you will see that the name of the calendar (most likely) as the last item in the url. It may have %20 where there were spaces in the name.

Look on the Site Hierarchy on the left of the page. Look through the list of items for something that might be a matching calendar to the one you are looking for.

If the calendar no longer exists, create a new calendar with the same url as the one that the Go to Calendar link points to. The link should now work if you named it the same.

If the link does not work the url is somehow different. In this case, you can try to correct the url difference recreating the site in a different path that will make the url correct.

Also, you don’t mind making it so officially Microsoft won’t support you, you can always do a search and replace in the content database. The SQL statement would look something like this:

update [dbo].[AllUserData]
set   [nvarchar4] = '/myoldpath/MyMeeting'
where [nvarchar4] = '/mynewpath/MyMeeting''

Please note that if you have delete an event a calendar you will need to create a new event and re-link the event to a workspace. You can do that by following the instruction here and then scroll to the “Create or link to a Meeting Workspace site when you create an event. “