Filter attributes
This page has moved to docs.servicestack.net/filter-attributes
ServiceStack also contains interfaces for attributes which can be executed before and after a request like request/response filters. The filter attributes are great for composing re-usable functionality as you can wrap common functionality in a Filter Attribute and selectively annotate which Services they should apply to.
For example, ServiceStack uses [Authenticate]
and [RequiredPermission]
filter attributes to decorate which Services should be protected with authentication or specific permissions (see Authentication and authorization).
You can create a Filter Attribute by implementing one of the Request or Response Filter interfaces below:
public interface IHasRequestFilter
{
void RequestFilter(IRequest req, IResponse res, object requestDto);
int Priority { get; } // <0 Run before global filters. >=0 Run after
IHasRequestFilter Copy(); // Optimization: fast creation of new instances
}
If you implement this interface, the method ResponseFilter
will be executed after the service was called.
public interface IHasResponseFilter
{
void ResponseFilter(IRequest req, IResponse res, object responseDto);
int Priority { get; } // <0 Run before global filters. >=0 Run after
IHasResponseFilter Copy(); // Optimization: fast creation of new instances
}
Method-level filter attributes are always executed just before/after the Service, i.e. the Priority is only scoped and sorted between other method-level attributes.
It's recommended that you create separate attributes for each interface, but of course you can implement both interfaces in one attribute, too.
public class CustomRequestFilterAttribute : RequestFilterAttribute
{
public void RequestFilter(IRequest req, IResponse res, object requestDto)
{
//This code is executed before the service
string userAgent = req.UserAgent;
StatisticManager.SaveUserAgent(userAgent);
}
}
public class CustomResponseFilterAttribute : ResponseFilterAttribute
{
public void ResponseFilter(IRequest req, IResponse res, object responseDto)
{
//This code is executed after the service
res.AddHeader("Cache-Control", "max-age=3600");
}
}
As you can see, you can access the IHttpRequest
, IHttpResponse
and the request/response DTO. So you can change the DTO, the http response (eg status code) or look for a specific header in the http request. You can also attach any data to this request via the IHttpRequest.Items dictionary that all subsequent filters and services can access.
These two attributes have to be added to a request/response DTO or to the service implementation to enable them.
//Request DTO
[Route("/aspect")]
[CustomRequestFilter]
public class User
{
public string Name { get; set; }
public string Company { get; set; }
public int Age { get; set; }
public int Count { get; set; }
}
//Response DTO
[CustomResponseFilter]
public class UserResponse : IHasResponseStatus
{
public string Car { get; set; }
public ResponseStatus ResponseStatus { get; set; }
}
...or if you don't want the code-first DTOs messed with attributes:
[CustomRequestFilter]
[CustomResponseFilter]
public class AspectService : Service
{
public object Get(Aspect request)
{
...
}
}
That's all, now ServiceStack recognizes the attributes and executes them on every call!
Just like in Services and Validators, the filter attributes are also auto-wired, e.g:
public class CustomRequestFilterAttribute : RequestFilterAttribute
{
//This property will be resolved by the IoC container
public ICacheClient Cache { get; set; }
public void RequestFilter(IRequest req, IResponse res, object requestDto)
{
//Access the property 'Cache' here
//This code is executed before the service
string userAgent = req.UserAgent;
StatisticManager.SaveUserAgent(userAgent);
}
}
In this case the property Cache
will be tried to be resolved by the IoC container.
ServiceStack also has two base classes, which implement the above interfaces, which make it easier to create contextual filters. Contextual filters are only executed on specific HTTP verbs (GET, POST...).
public class StatisticFilterAttribute : RequestFilterAttribute
{
//This property will be resolved by the IoC container
public ICacheClient Cache { get; set; }
public StatisticFilterAttribute() {}
public StatisticFilterAttribute(ApplyTo applyTo)
: base(applyTo) {}
public override void Execute(IRequest req, IResponse res, object requestDto)
{
//This code is executed before the service
string userAgent = req.UserAgent;
StatisticManager.SaveUserAgent(userAgent);
}
}
The
ResponseFilterAttribute
base class can be used for Response Filter Attributes which works the same asRequestFilterAttribute
above.
The base class RequestFilterAttribute
has an empty constructor and a constructor which takes the ApplyTo
flag. If the empty constructor is called, the method Execute
will be called on every HTTP verb (ApplyTo.All
), with the other constructor it will be called only on the configured HTTP verbs (eg ApplyTo.Get | ApplyTo.Post
).
So you can use the attribute on your request DTO/service like that:
//Filter will be executed on every request
[StatisticFilter]
...
//Filter will be executed only on GET and POST requests
[StatisticFilter(ApplyTo.Get | ApplyTo.Post)]
...
- Why ServiceStack?
- Important role of DTOs
- What is a message based web service?
- Advantages of message based web services
- Why remote services should use separate DTOs
-
Getting Started
-
Designing APIs
-
Reference
-
Clients
-
Formats
-
View Engines 4. Razor & Markdown Razor
-
Hosts
-
Security
-
Advanced
- Configuration options
- Access HTTP specific features in services
- Logging
- Serialization/deserialization
- Request/response filters
- Filter attributes
- Concurrency Model
- Built-in profiling
- Form Hijacking Prevention
- Auto-Mapping
- HTTP Utils
- Dump Utils
- Virtual File System
- Config API
- Physical Project Structure
- Modularizing Services
- MVC Integration
- ServiceStack Integration
- Embedded Native Desktop Apps
- Auto Batched Requests
- Versioning
- Multitenancy
-
Caching
-
HTTP Caching 1. CacheResponse Attribute 2. Cache Aware Clients
-
Auto Query
-
AutoQuery Data 1. AutoQuery Memory 2. AutoQuery Service 3. AutoQuery DynamoDB
-
Server Events
-
Service Gateway
-
Encrypted Messaging
-
Plugins
-
Tests
-
ServiceStackVS
-
Other Languages
-
Amazon Web Services
-
Deployment
-
Install 3rd Party Products
-
Use Cases
-
Performance
-
Other Products
-
Future