Closed marcrocny closed 6 years ago
Hi @marcrocny, thanks for your feedback! Looking at the Microsoft implementation for Twitter, for example, I don't see them invoking anything on the Events giving a chance to the application to add more claims to the ClaimsIdentity. It sets the 4 predefined claim types with values returning from 'ObtainAccessTokenAsync' call but that's it. Perhaps I'm missing something?
I wasn't aware of the EventsType hook when I wrote this. Perhaps it could use this API instead to be closer to the other Microsoft written handlers. What would you suggest?
I took a look at the code and it does calls into Events
with the newly created ClaimsPrincipal.
That's the hook for the application to modify it or even reject the user by calling AuthenticationSucceededContext.Fail
during CredentialsValidated
@marcrocny I'll close the issue for now. Feel free to reopen if my last comment doesn't solve your problem.
I also needed to persist some additional claims which I get during DB lookup, so I slightly modified the code: my commit
I'd be happy to merge a pull request with your changes.
Although I'm not a big fan of passing a mutating collection like that, I see it solves the problem rather simply. And changing to code now to abandon the original idea of the generic argument for registration in favor of the EventsType approach is not really worth it as it'll break everyone using this for little value.
The extension only allows for a
bool
response and automatically fills in a contextualClaimsPrincipal/CliamsIdentity
with just the username. There's no way (that I can see) to provide an extension to the claims included there without fully overridingBasicAuthenticationHandler.HandleAuthenticateAsync()
which kind of obviates the purpose of the class.Note also, for what it's worth: while I like (maybe prefer) the "direct injection" method used here, the more "aspnetcore-correct" way of doing this would appear to be adding the injected authentication method to an "*AuthenticationEvents" object that is configured either directly on
AuthenticationSchemeOptions.Events
or indirectly by setting the type onAuthenticationSchemeOptions.EventsType
. The latter uses dependency injection to create the events-object anyway, but there you are.