[Prototype] Rework events (support DI)

[HaoK]

• Nukes all IAuthEvents interfaces
• Introduces AuthenticationEvents base which contains Type EventsType which causes DI replacement of the events instance if set

Seems fairly seemless, no tests needed to be updated with this change surprisingly... I added one for cookies to pull its events from DI

@Tratcher @PinpointTownes @davidfowl

[dnfclas]

Hi @HaoK, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.

TTYL, DNFBOT;

[kevinchalet]

Getting rid of the interfaces would be a cool change as we could introduce new events without breaking the contract... but are you sure it's really non-breaking? (I'm tempted to think it's a binary change 😨)

[kevinchalet]

Same remark as in the other PR, doing that at this stage won't allow using scoped event classes. It's something you'd have to do in CreateHandler or directly in the handler.

[HaoK]

Bleh, will require more plumbing then :(

[HaoK]

@PinpointTownes this is meant to be a breaking change :)

[kevinchalet]

@HaoK ah, it would have to wait until 2.0 then, right?

[HaoK]

Yes but we are just validating the design with a prototype right?

[HaoK]

Removed the one time resolution of the events type from the base middleware, and updated JwtBearer and cookie to demonstrate the new pattern:

Each events class will have (yet another) new method that hides a ResolveEvents(IServiceProvider services) that will replace or return itself. The handlers will all use this method with context.RequestServices instead of directly using Options.Events

[kevinchalet]

Yes but we are just validating the design with a prototype right?

Sure. But removing the interfaces is orthogonal. The "events type" thingy could be added in a non-breaking way, no?

Removed the one time resolution of the events type from the base middleware, and updated JwtBearer and cookie to demonstrate the new pattern:

So, to make things clearer (for me 😄), to use a specific events class, I'd have to do something like that:

app.UseJwtBearerAuthentication(new JwtBearerOptions {
    Events = new JwtBearerEvents {
        EventsType = typeof(MySuperEventsClass)
    }
});

... right?

It seems odd to me that you have to instantiate a JwtBearerEvents object to tell the system "hey, yeah, I provide you with this events class instance, but actually, you won't really use it. Instead, you'll resolve the DI-injected service represented by EventsType".

[HaoK]

Sure but this PR is taking a look at all the events changes we'd like to make, not trying to scope this down since this is more of a prototype for now...

In regards to the usage, its a bit clunky due to no lambda so you can't inline:

var options = new JwtBearerOptions();
options.Events.EventsType = typeof(MySuperEventsClass);
app.UseJwtBearerAuthentication(options));

[kevinchalet]

In this case, we could also reconsider aspnet/Options#11 for 2.0.

[HaoK]

Not sure we want to add anything to options regarding this anymore, but we could certainly see if there's anything that makes sense to add to DI to make this pattern easier.

[Tratcher]

Using this as a base class isn't helpful when everybody just overrides it (and awkwardly at that).

[HaoK]

Will be replaced as part of #1065