Make internal ServiceLocator overridable with external

[chrisism]

I like to use an own implementation of ISecurityHandler, but it looks like FluentSecurity is resolving this only with the internal ServiceLocator.

I have a controller with open generics. I cant set the security for this controller correctly since the configuration.For() doesn't allow open generics. So having BasicController<T> I cannot use configuration.For<BasicController<>>()

The T is resolved runtime and now I am getting the 'Security has not been configured for controller' exception because it cannot find a PolicyContainer supporting the BasicController with runtime generic.

Now I was looking to implement an own version of ISecurityHandler which will handle this situation, but as stated before, I cannot seem to provide my own implementation, even if I use the configuration.ResolveServicesUsing() method.

[chrisism]

Okay, seems that it does use the external ServiceLocator using it normally in a webapp. But I tried it in a testclass with the SecurityConfiguration.Current.Verify(..) and there it doesn't call the the custom ServiceLocator

[kristofferahl]

Sorry for the late reply. I'm a bit unsure of what you were expecting it to do when using SecurityConfiguration.Current.Verify(..)?

Verify will verify that you have applied policy X to controller/action Y. ISecurityHandler is not a part of this process as it is only used at runtime.

[chrisism]

You are quite right. I was trying to test it with open generic controllers. This depends quite some on the service locator. You might say that indeed this is out of scope of the unittest/verify method.

But lets change this to a feature request in which I like to more easily define the security for an open generic controller: configuration.For<MyController<>>().RequireAnyRole(....)

[kristofferahl]

You say "more easily define the security for an open generic controller"... What exactly is the end result that you are after? Are looking to apply policies to all controllers inheriting from MyController<>?

If so, yes we should be able to support this. It should not be a lot of work extending ForAllControllersInheriting<>() so that it allows open generics.

[chrisism]

That is indeed the the thing. In my situation the generic type T is injected every time through service location. So I do not have a MyController<MyType> defined. Since all the injected generic types have to inherit a base class I used ForAllControllersInheriting and let MyController<T> inherit from a base class. The main problem I had is how SecurityHandler resolved the controller name in the HandleSecurityFor method. Since it will get the generic controller it can not resolve the security for that controller. I did my own ISecurityHandler implementation with a decorator pattern for the default SecurityHandler. When it gets the generic controller name it will take the name of the base class and pass that through. Then it will find the correct security, set earlier with ForAllControllersInheriting. This solved it for me now, but I dont like a mandatory base class for my controller. So if can just define security for an open generic controller I can make it a bit cleaner. Thanks