Add rule to parametrized Action

[baio]

Hi! Is there some way to add authorization rule on parametrized Action. For example:

configuration.For<AccountController>(x => x.Edit(?))

[kristofferahl]

Sorry for the late reply!

At the moment there is no way to do it like that but if you expand a bit on your scenario maybe I can guide you and help you find a solution. What is it that you would like to do?

[baio]

Hi! It's just common case scenario, for example for AccountController, where I have some action with two parameters ServiceName and ReturnUrl. In generally some actions have required parameters and I wan't loose convenience of MVC of auto binding for request parameters. By the way if for some action I set authorization logic by FluenSecurity and then use just regular mvc attributes, such as Autorize, which is more prioritazable?

[kristofferahl]

I can imagine what you are after and I'm afraid that isn't possible at the moment. But if you can provide me with a strong case for why it would be good to have I will consider adding it to the todo-list. Or you could just fork the repository and add the feature yourself.

Regarding AuhtorizeAttribute I am not sure in what order they will execute but I really don't see in what case you would like to use both. You can easily ignore a certain controller action by adding the IgnorePolicy to that action. That way, Fluent Security will do nothing so it shouldn't matter in what order they come into play.

[baio]

ok, thanks!

[kristofferahl]

Just to let you know. I'm currently looking into adding support for this in v.2.0. You will be able to check route values in your policies. It might not be as easy as what you asked for but it would get the job done I believe. However, if you can come up with a nice syntax for defining route value rules I might just add that as well. I'll leave this issue open for now.

[baio]

Hi! Thank you for this reply. The only way is to come into my mind is a Func<...> with predefined number of parameters in it. Like it is implemented in general framework

Func<T1, T2, ActionResult>
Func<T1, T2, T3, ActionResult>

...so on Func<T1, T2, ..., T7, ActionResult> for example

This way in fluent security I could define fluentSecurity.ActionSecurityPolicy<Controller, int, string>((Contrioller, IntParam, StrParam)=>Controller.Action(IntParam, StrParam));

Something like this.

[mariusschulz]

I can only support that feature request. That is indeed a common scenario.

Say, for example, you have a ProductController with an Edit action method that looks like the following (simplified):

public ActionResult Edit(int id)
{
    bool userCanModifyProduct = /* Insert Business Logic here */;

    if (!userCanModifyProduct)
    {
        return View("NotAuthorized");
    }

    Product product = _productRepository.Retrieve(id);

    return View(product);
}

Problem: That authorization logic has to be repeated within the Edit action method for POST requests, for both GET and POST versions of the Delete action method, and maybe even more.

Solution: It would be nice to be able to encapsulate that logic in a custom Policy and secure those actions once in a centralized place. That would also help to simplify controllers and remove redundant clutter.

[kristofferahl]

I've done some work in this area. You can follow the progress in the "spike-extend-security-context" brach located here: https://github.com/kristofferahl/FluentSecurity/tree/spike-extend-security-context

There is now support for reading route values from the ISecurityContext so you can use those to secure your actions. If you will be doing a lot of context.Data.Get<T>() in your policies there is also an option to encapsulate that in a custom ISecurityContext and then use the base class SecurtityPolicyBase<TCustomSecurityContext>. Have a look at Bootstrapper.cs in the sample application for examples of both.

[mariusschulz]

Just wanted to update you: I read your email, your GitHub update, and your Twitter direct message — I will take a look at it on the weekend!

-----Ursprüngliche Nachricht----- Von: Kristoffer Ahl [mailto:[email protected]] Gesendet: Wednesday, January 11, 2012 12:08 PM An: Marius Schulz Betreff: Re: [FluentSecurity] Add rule to parametrized Action (#9)

I've done some work in this area. You can follow the progress in the "spike-extend-security-context" brach located here: https://github.com/kristofferahl/FluentSecurity/tree/spike-extend-security-context

There is now support for reading route values from the ISecurityContext so you can use those to secure your actions. If you will be doing a lot of context.Data.Get<T>() there is also an option to encapsulate that in a custom ISecurityContext and then use the base class SecurtityPolicyBase<TCustomSecurityContext>.

---

Reply to this email directly or view it on GitHub: https://github.com/kristofferahl/FluentSecurity/issues/9#issuecomment-3452666

[mariusschulz]

Looks good to me!

[kristofferahl]

Just pushed and update to the spike branch. Decided that I wanted to make this feature a part of the current configuration. But instead of adding it to the configuration directly you will reach it using configuration.Advanced.

configuration.Advanced.BuildContextUsing(innerContext => new CustomSecurityContext(innerContext));
configuration.Advanced.BuildContextDataUsing(contextData =>
{
    contextData.Set(HttpContext.Current.Request.AcceptTypes, "AcceptTypes");
    contextData.Set(HttpContext.Current.Server.MachineName, "MachineName");
});

The plan is to start adding the more advanced features there so that we won't suffer from feature explosion when working with the most common scenarios.

I should also add that you only need to us BuildContextUsing if you haven't register the context in an IoC-container. You don't need to do anything if the constructor of your context only takes a single argument of ISecurityContext.