ServiceStack/ServiceStack — pull request #901 by Its-Tyson (2014-04-13 08:52:10+00:00)
Title: Added ability for razor content pages to participate in request filter pipeline

I love the razor 'Content Pages' feature of SS and how it removes all the controller/service ceremony when its not needed. But one thing I have been finding myself doing is when I need to protect a content page behind a login, I have had to revert back to creating a dummy DTO and service with just the `[Authenticate]` attribute on it mapping to a View Page instead.

Content Pages that inherit from `ViewPage` already construct and populate the view model `T` from the query string and form data, just like service DTOs, so I tried to chuck an `[Authenticate]` attribute on the view model type, but obviously it didn't do anything. These content page view models already kinda define a message contract, so why not have them participate in the full request/response pipeline that service DTOs participate in.

This PR does just that, in a very rough way, only running the request filters currently (i.e. no response filters). It's more just to start a discussion on if this is something useful? It still feels a bit weird to me, e.g. if the page does have such an explicit message contract, or advanced behavior to warrant filters, why not make it explicit in a DTO and service. On the other hand, it is very useful for getting stuff done quickly, and recently I have been making all pages content pages, even ones that need to render service results (by resolving the required service and calling it within the razor content page) - this creates a clean separation between services and views, and also makes it much easier for web designers to work on (they don't have to worry about finding pages in the Views directory, everything maps straight from the url path to the filesystem as they expect).

Another option (which actually might be able to be built on top of this) is custom razor directives for content pages, e.g. `@authenticate`