We have a base controller which all of our other controllers inherit and a custom RequireHttps attribute. This custom attribute has a switch to either force SSL or to rely on a setting in a config file. The base controller is decorated with this attribute and set to rely on the config setting, which is the correct behavior for 95% of our controllers. We have a couple controllers, however, that we want to set to always require SSL. If I apply the attribute to those couple controllers to force SSL then the RequireHttpsAttribute code is run twice (probably not a huge problem, but certainly not ideal).
Is there any way for me to override the attribute declaration on the base class with the attribute declaration on the child? I suspect I cannot, but would like to know for sure.
Thanks All
How about creating another custom attribute which will inject into the current HttpContext some value indicating that SSL is required. Then you will decorate the controllers that need to be an exception with this attribute. Then modify your custom RequireHttps attribute yo look for the presence of this value in the HttpContext and enforce SSL.
You only need to ensure that this new filter will run before the custom RequireHttps attribute. This could be done either using the Order property.
Related
I've started looking into ASP.NET core, in particular Authorization. The model's changed quite a bit and I must say I'm finding it a little confusing compared to the last implementation.
I've seen various posts lamenting that it's now not possible to pass parameters to the Authorization attribute constructor and that instead we now have Policy/Requirement/Handler.
So what exactly is the user case for AuthorizeFilter? How does it differ from AuthorizeAttribute? When should I implement Requirement/Handler and when (or should I ever) implement an AuthorizeFilter (which looks like it might work closer to the old model)?
I couldn't find any resources online that detailed this particular aspect so any enlightenment is greatly appreciated.
The Documentation above the class of AuthorizeFilter says:
MVC recognizes the <see cref="T:Microsoft.AspNetCore.Authorization.AuthorizeAttribute" />
and adds an instance of this filter to the associated action or controller.
So when a controller is created an instance of the AuthorizeFilter is added to the controllers filters when a AuthorizeAttribute is present.
Basically they split the decoration: AuthorizeAttribute from the implementation: AuthorizeFilter.
So if you want clean code you can use AuthorizeAttribute to decorate your controller class.
if you want more understandable/logical code you can add te AuthorizeFilter to the filters in the Controller Constructor method.
I could using [Bind("properties to include")] on an MVC action in ASPNET MVC 4. How do I restrict binding to specific properties using AspNetCore/MVC6? (RC2)
You could use JSON.NET's JsonIgnoreAttribute on properties which you want to exclude from deserialization, but note that this also makes the property not to serialize also. (Ideally you should have a model which is exactly what you expect from the user instead of ignoring certain properties, but I am not aware of how your requirements are)
So, I have a viewmodel class in a xamarin project that I inject some dependencies into via ninject binding on app start. One of these is an IDialogService.
When my MainPage in my application changes it raises a property changed event and I rebind the implementation of the dialog service since it is tied to the MainPage.
If my viewmodel has already been created with lets say DialogServiceA and then when MainPage changes we rebind to DialogServiceB, will my viewmodel be using service A or B? I think it is using A and therefore does not display in the UI because it is tied to a MainPage that no longer exists.
So, if this is the case how can I dynamically change my dialog service but then update classes that have already been instantiated without changing everything to get the current dialog service from the container every time its used (therefore not injecting it at all really, and doing more of a servicelocator)
Also, if this approach is completely wrong, set me straight.
You're right. Re-configuration of the container does not affect already instanciated objects.
If you want to change dependencies without re-instanciating the dependent (parent ViewModel) there's a few possibilities for you:
use a factory to instanciate the service every time. Implement an Abstract Factory (Site by Mark Seeman) or use Ninject.Extensions.Factory to do so
instead of injecting a service directly, inject an adapter. The adapter then redirects the request to the currently appropriate service. To do so, either all service can be injected into the adapter, or you can use a factory as with the possibility above.
instead of inject a service directly, inject a proxy. The proxy is quite similar to the adapter, but instead of coding every method / property redirection specifically, you code a generic redirect by an interceptor. Here's a tutorial on castle dynamic proxy
At the end of the day, however, i believe you'll also need a way to manage when to change the service / which it should be. There's probably a design alternative which doesn't rely on exchanging objects in such a manner.. which would make it an easier (and thus better?) design.
Edit: i just saw that you also tagged the question as xamarin-forms. In that case it most likely won't be an option to use either a dynamic proxy nor ninject.extensions.factory (it relies on dynamic proxies, too). Why? dynamic proxy / IL emitting is not supported on all platforms, AFAIR specifically on Apple devices this can't be done.
I have the following bindings declared
Bind<IDataSource>().To<DataSourceOne>();
Bind<ISettings>().To<DataSourceSettings>
.WhenInjectedInto<DataSourceOne>();
Bind<ISettings>().To<Settings>();
now I call
Kernel.Get<IDataSourc>();
Ninject correctly injects a DataSourceSettings, but I need to pass a constructor argument to Settings and DataSourceSettings based on data from a config file. so I've changed the IDataSouce binding as follows
Kernel.Bind<IDataSource>().To<DataSourceOne>()
.WithConstructorArgument("settings", Kernel.Get<ISettings>(
new ConstructorArgument("data", objectContainingConfigFileData)
)
);
in that case Ninject injects Settings class instead of DataSourceSettings class. I assume the problem is that the ISettings is getting resolved before it is injected into the DataSourceSettings class so Ninject does not use the binding I intended it to. Is there a way to get around this. I haven't found anything yet.
It should work if you define the constructor argument for the ISettings binding and not for the DataSource binding. Assuming you already know the object with the config file data in the module. Otherwise maybe a factory would be more appropriate.
kernel.Bind<IDataSource>().To<DataSourceOne>();
kernel.Bind<ISettings>().To<DataSourceSettings>()
.WhenInjectedInto<DataSourceOne>()
.WithConstructorArgument("data", objectContainingConfigFileData);
kernel.Bind<ISettings>().To<Settings>();
I have a situation where I want to dependency inject my user object, but also place the current user in the IoC container. I want the following lines to work:
kernel.Get<User>(); // Should return a new User()
kernel.Get<User>("Current"); // Should return the current user
One might think bindings like this would work:
Bind<User>().ToSelf();
Bind<User>().ToMethod(LoadCurrentUser).InRequestScope().Named("Current");
Of course, that gives:
Ninject.ActivationException: Error activating User
More than one matching bindings are available.
Activation path:
1) Request for User
Suggestions:
1) Ensure that you have defined a binding for User only once.
I understand the error since a Named binding does not restrict the application of that binding, so both bindings apply. It seems clear that I need to use the contextual bind with the .When*() methods but I can't come up with any way to do that. I feel like there should be when methods that detect whether a named instance is applied. Something like:
// Not valid Ninject syntax
Bind<User>().ToSelf().WhenUnnamedRequested();
Bind<User>().ToMethod(LoadCurrentUser).WhenNamedRequested().InRequestScope().Named("Current");
I can't find any place on the IRequest interface or it's properties that tells me the name requested. How do I do this?
This question was answerd on the mailing list:
http://groups.google.com/group/ninject/browse_thread/thread/cd95847dc4dcfc9d?hl=en
If you are accessing the user by calling Get on the kernel (which I hope you do not) then give the first binding a name as well and access User always by name. Actually, there is a way to get an instance from the binding without a name. But because I heartily recommend not to do this, I do not show how to to this here. If you still want to do it this way I'll tell you later how this would work.
If you are doing it the better and prefered way and inject the user to the objects that require it as dependency there are two options:
The easier one: Give the first binding a name and add a named attribute to the parameters e.g. ctor([Named("NewUser") IUser newUser, [Named("Current")] IUser
currentUser)
Or the prefered way to keep the implementation classes free of the IoC framework: Specify custom attributes and add them to the parameters e.g. ctor([NewUser] IUser newUser, [CurrentUser]IUser currentUser). Change the Bindings to:
Bind<User>().ToSelf()
.WhenTargetHas<NewUserAttribute>();
Bind<User>().ToMethod(LoadCurrentUser)
.InRequestScope()
.WhenTargetHas<CurrentUserAttribute>();