I'm trying to create an abstract surface controller, so that I can create two controllers that derive from it.

Controll B will not have the IsBackOffice and Controller C will. Both Controller B and C will derive from Controller A.

The goal here is I want one to authenticate as a Member and the other to Authenticate as a User.

Both The front end and back end share some controller methods, hence the inheritance.

However the back end has some extra methods that only Backoffice users should be able to do.

The front end controller has some methods that only front end members should do.

The problem is that Umbraco ignores surfaces controllers on authentication in the back office (OnAuthenticateRequest does not run on /umbraco/surface/someSurface or /umbraco/somearea/somesurface...

I tried tagging my back office version with IsBackOffice but the router ignores Surface controllers.

Umbraco routing only respects IsBackOffice if the controller is an API controller.

I don't want to use an API controller because I want to return ActionResults (even in the back office angular layer I can still use action results)...

I can call my surface controller from a property editor in the back office, that's no problem at all...

However if I try to get the user logged in, it's the Member every time.

So I popped open reflector and noticed SurfaceController derives from Plugin Controller. And Plugin Controller has PluginMetaData which has a property called IsBackOffice which it populates from the IsBackOffice attribute.

So I can decorate my SurfaceController with IsBackOffice and PluginMetaData will have it...

However the route function in the WebBootStrapManager doesn't do anything with IsBackOffice on surface controllers, only on API Controllers. However umbraco doesn't do anything with it, it's like code that does stuff and never get's used, serves no purpose...

If I want to return ActionResult's and process razor views in a controller that authenticates int he back office, I can't. The only two controllers that inherit from MVC.Controller are PluginController and SurfaceController.

PluginController itself is abstract, and is not routed at all. So if I derrive from PluginController no routing happens, I'd have to route it myself.

So to get around this I would need to Override the global.ascx with a custom UmbracoApplication derriving from UmbracoAplication. Then I would need to override GetBootstrapManager().

Build a custom WebBootstrapManager that derrives from webbootstrapmanager...

And then I'm stuck because RoutePluginController is private and not virtual.

So I would need to go even lower, derriving from CoreBootManager... Then reduplicating all the logic in WebBootManager with the addition of create a back office surface controller route.

I might even need to modify UmbracoModule's ShouldAuthenticateRequest to authenticate the new back office surface route.

Was this intended, or maybe possibly an oversight?

I guess I could bite the bullet and use API controllers in the back office that return json and no razor views, but I really don't want to maintain two separate frameworks.

If I could get around this I could share parts of my frontend controller with the back office.

Optionally again, I could design my back office permissions on front end members, but that could get confusing real quick. Would be a lot easier if umbraco only had one users store (E.g. just users, not users and members).