Authorization Edit Rule with an objects Id available

[ImmutablLimited]

Hi, sorry if this (or similar) has been asked 1,000,000 times about what kind of rule for what kind of situation... I have tried to look.

In terms of some context

• I have an entity - say a project
• I have a business object - say editProject
• I have a blazor page - say EditProject/{id}

I want to be able to execute some rules to limit access to:

1. display the edit form (based on user identity roles)
2. display the model content (based on database check of a user permissions table)

I can achieve 1. reasonably easily with an Authorization rule for the EditObject action and a quick check of context.ApplicationContext.User.IsInRole("Role") in order to determine if context.HasPermission is set to true or false. Then on teh Blazor page simply wrap the form with an if based on the CanEditObject property on the view model.

I am really struggling with 2. as I cannot work out how to get hold of the Id property of the business object in question as context.Target is always null at the point the rule is run so I cannot access the target to get the Id.

The authorization rule seems to execute immediately on adding the rule which occurs before the properties are set (adding a breakpoint to the auth rule AddRule statement and the property setter hits the auth rule add first, which executes the rule and thus sets the CanEditObject bool with no properties set or object instantiated, and then moves on to the property setter)

This framework seems, to my odd little mind, to be really logical and obvious in terms of its application to rules apart from this which I cannot get my head around.

Any help gratefully received.

[rockfordlhotka]

Per-type rules operate on the type, not on any specific instance of the type. As a result, per-type rules can't solve the problem of whether the user can edit a specific object, only whether the user can edit any of the object type.

To prevent the user from editing a specific object, you'll need another mechanism.

One way to do this is for the object's data portal fetch operation to throw an exception to indicate the current user isn't authorized to edit the specific object. The UI would have to handle the DataPortalException and check its BusinessException to see if the result is an authorization issue.

Another way to do this is to do a two-part process. Use a command object to find out if the user is authorized to edit the specific object instance, and only have the client call the fetch if the user is authorized. The drawback here is that the normal case requires two data portal calls, which seems inefficient.

Yet another way is to use a UoW or command object to do both things at once. Sort of like this:

[Serializable]
public class GetProject : CommandBase<GetProject>
{
    public static readonly PropertyInfo<bool> IsUserAuthorizedProperty = RegisterProperty<int>(nameof(IsUserAuthorized));
    public bool IsUserAuthorized
    {
        get => ReadProperty(IsUserAuthorizedProperty);
        private set => LoadProperty(IsUserAuthorizedProperty, value);
    }

    public static readonly PropertyInfo<Project> ResultProperty = RegisterProperty<Project>(nameof(Result));
    public Project Result
    {
        get => ReadProperty(ResultProperty);
        private set => LoadProperty(ResultProperty, value);
    }

    [Execute]
    private async Task ExecuteAsync(int projectId, [Inject] IDataContext Db)
    {
        IsUserAuthorized = true; // check authorization

        if (IsUserAuthorized) 
        {
          var project = await Db.Projects.FindAsync(projectId);
          Result = project;
        }
    }
}