Support Stunts / Actions

[khalidabuhakmeh]

Stuntman is currently focused on Authentication scenarios, but I believe it can do more.

I would like to propose the idea of a Stunt:

A stunt is a code block that can be executed at will from the UI that may or may not require input, and additionally may or may not return a result to the developer. Stunts can only be performed during development.

Code (pseudo)

Here is what implementing a stunt may look like in code.

public class ResetPasswordVerificationKeyStunt : Stunt {
     // set by StuntCoordinator
     public string UserId { get; set; }

     public override string Perform(StuntContext context) {
            var container = context["Container"] as Container;
            var db = container.Resolve<UserRepository>();

            var token = Guid.NewGuid().ToString("D");
            var user = db.GetUser(UserId);

            user.VerificationKey = token;
            db.Save(user);

            return $"token : {token}";
     }
} 

Then you would register this action with the StuntmanOptions

StuntmanOptions
   .AddStunt<ResetPasswordVerificationKeyStunt>();

UI

[kendaleiv]

I suppose the decision here is do we want to limit Stuntman to authentication related things only, or if we want to invite and allow other functionality. I'm not outright opposed to expanding its capabilities, and it seems potentially helpful to have a commonly known place for all those little things you could need to do at development time.

Ideally items commonly needed are available on the proposed StuntContext. If it's to request items from an IoC container, that container will need to be built and ready. Which, could be tricky as we didn't design Stuntman purely for ASP.NET MVC where we can depend on IDependencyResolver or similar.

Right now Stuntman is focused purely on authentication (with authorization supported thru the use of claims). Would we want to bake this into the main library? Or, should this be a second package? Although, we could potentially use namespaces to accomplish that goal. It seems like a second package might be unnecessary -- just asking the question.

I wonder what @billboga thinks. :smiley: