Exercise 2: Exception Handling Strategies
In this exercise you will secure part of our
application service with Code Access Security and then use a
Replace Handler with the Exception Management Application
Block to hide sensitive information from clients. You will also show
how you can filter which exceptions escape the top application
layer.
First step
View the Service Modifications
- Open DictionaryService.cs in the
PuzzlerService project.
You added a new class to the
PuzzlerService project, named DictionaryService. This class
acts as a Service
Interface on top of the Dictionary
class. Within this class you provide exception filtering and
transformation before sending the results back to the
client. For techniques to intercept the call and
automatically transform and handle exceptions, see the "Developing
Microsoft® .NET Service-Oriented Applications" course
of
Mastering Industrial Strength .NET.
Protect the Service's 'Add Word' Functionality
with Code Access Security
- Open Dictionary.cs in the PuzzlerService
project. Find the AddWord method and decorate
it with a security attribute as follows:
[System.Security.Permissions.PrincipalPermission(System.Security.Permissions.SecurityAction.Demand,
Role="Grand PoohBah")]
public static Boolean AddWord(string wordToAdd)
This method can now only be executed by a user who is a
member of the role Grand PoohBah, an
unlikely situation.
Note: Decorate the AddWord method in
Dictionary.cs not DictionaryService.cs.
- Run the application, type a nonsense
word (alphabetic - no numbers!) into the 'Word To Check' textbox
(ensure that you have an error flashing), then click on the
Add Word button. This will call the service's
AddWord function and throw a SecurityException,
which you can check in the event viewer.
The SecurityException may be serialized
from a Server to a Client (over Web Services) and contains
information that may help an attacker break our
security. You would prefer to catch and log the security
exception on the server, then pass an exception containing
less information to the client.
- Close the application.
Configure the application to replace
SecurityExceptions
-
Run the Enterprise Library Configuration tool. From the
Windows Start menu select All
Programs | Microsoft patterns and practices | Enterprise
Library | Enterprise Library Configuration.
-
Select File | Open Application and browse
to the App.config file located
here (in the ex02/begin/PuzzlerUI
project).
Note: Do not use any
existing Application Configuration that you may already have
open - this will be for the previous exercise. Ensure that
you Open the App.config for Ex02!
-
You have already created a policy, named Service Policy. By
default, if a policy is empty, then exceptions will just be
re-thrown inside the catch block, so in effect the policy
will do nothing.
Add a new Exception Type:
System.Security.SecurityException to the Service
Policy. Change the PostHandlingAction for
the SecurityException to ThrowNewException.
- Add a new Logging Handler
to the SecurityException exception type, and
change the following values:
LogCategory: General
Title: Security Exception in Service Layer
- Add a Replace Handler for the
SecurityException exception type. Change the ExceptionMessage
to "Unauthorized Access", and select
System.Security.SecurityException from mscorlib
as the replacement exception type from the type selector dialog.
Although you have kept the type the
same, by creating a new SecurityException, this will not
provide the client any of the stack information or internal
security exception information, which could compromise
security.
Change the Application to Exit on a Security
Exception
- To add a new exception type under
UI Policy of
System.Security.SecurityException. Leave the
PostHandlingAction as NotifyRethrow, which will
cause the handler for the Application.ThreadException event to
re-throw the exception, and shut down the application.
- Add a Logging Handler
to the SecurityException under UI
Policy, and change the property values to:
LogCategory: General
Title: Security Exception in UI Layer
- Save the current application in
Enterprise Library Configuration using File | Save All.
Test the Replace Handler
-
Run the application, type a nonsense (alphabetic) word into
the Word To Check textbox (ensure that you
have an error flashing), then click on the Add Word
button. If debugging click on Continue
when it displays an "Unhandled exception" message. Open the
event log to look at the events created. You can use the
debugger to observe exactly what is happening and relate
this to the Exception Handling Policies.
This time the Exception will be shown three times in the
Event Log.
First a SecurityException is captured in Dictionary.cs.
This is caught by the service layer (DictionaryService.cs)
which applies Service Policy. This will cause the
exception to be written to the event log on the server
(with all available information included) and then will
capture a new replacement SecurityException (without
specific stack information).
Second the replacing SecurityException is caught by the
Application ThreadException handler in Startup.cs. This
applies UI Policy which will write the
exception to the event log on the client (the same
machine in our case) and set the re-throw boolean to
true which allows our code to decide to re-throw the
second SecurityException.
Third the re-thrown SecurityException is caught by our
AppDomain UnhandledException handler (it was thrown from
outside the Application.Run) which applies Unhandled
Policy. This will log the exception and display a
MessageBox informing us that there was an error in the
application.
The AppDomain UnhandledException handler does not
consume exceptions, so the exception continues to pass
to the runtime or debugger exception handler. This will
cause a standard unhandled exception dialog box to be
displayed.
|