Skip to main content

Interceptors

Interceptors allow you to process validation and business logic before and after Entities hit the database.
For example, you may need to validate some external business rules before the object is saved, but then after it’s saved, you may need to dump the object to an Azure Storage Queue to get picked up by a WebJob for further processing out-of-band.
The way RESTier accomplishes this is virtually identical to the Method Authorization feature. This means there are once again two different approaches to tackle the task.
No matter what approach you choose, the concept is simple. Either technique uses a function that returns boolean:
  • Return true, and processing continues normally
  • Return false, and RESTier returns a 403 Unauthorized to the client

Convention-Based Interception

Users can control if one of the four submit operations is allowed on some entity set or action by putting some protected internal methods into the Api class. The method name must conform to the convention:
The possible values for {BeforeOperation} are:
  • Inserting
  • Updating
  • Deleting
  • Executing

Example

The example below demonstrates how both types of {TargetName} can be used:
Shows validation before inserting - checks if the Trip Description is not blank
Shows processing after inserting - logs the operation and could trigger additional business processes
TrippinApi.cs

Centralized Interception

In addition to the more granular convention-based approach, you can also centralize processing into one location.
Users can use interface IChangeSetItemAuthorizer to define any customized authorize logic to see whether a user is authorized for the specified submit. If this method returns false, then the related query will get error code 403 (Forbidden).
There are two steps to plug in the centralized authorization logic:
1

Create authorizer class

Create a class that implements IChangeSetItemAuthorizer
2

Register with DI

Register that class with RESTier through Dependency Injection (DI)

Example

CustomAuthorizer.cs
NEEDS CLARIFICATION:In CustomizedAuthorizer, user can decide whether to call the RESTier logic. If user decides to call the RESTier logic, user can define a property like private IChangeSetItemAuthorizer Inner {get; set;} in class CustomizedAuthorizer, then call Inner.Inspect() to call RESTier logic which calls Authorize part logic defined in section 2.3.

Unit Testing Considerations

Because both of these methods are de-coupled from the code that interacts with the database, the Authorization logic is easily testable, without having to fire up the entire Web API + RESTier pipeline.

Setting up your Unit Test

1

Create test project

If you don’t have a unit test project for your API project already, start by creating one. Repeat the process outlined in “Getting Started” to install the RESTier packages into your Unit Test project.
2

Add FluentAssertions

Add the FluentAssertions package to your test project:
3

Make internals visible

Go back to your API project. Expand the “Properties” node, double-click AssemblyInfo.cs, and add the following line to the very end of the file:
Make sure you replace {TestProjectAssembly} with the actual assembly name. This is important, because otherwise the tests won’t be able to see the protected internal methods the authorization conventions use.

Example

Given the Convention-Based Authorization example, the tests below should have 100% code coverage, and should pass without any required changes.
TrippinApiTests.cs