Port Facebook middleware from Katana. #34
Conversation
| { | ||
| app.UseServices(services => | ||
| { | ||
| services.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType); |
There was a problem hiding this comment.
In this PR. This data used to be stored in IAppBuilder.Properties, but everything there moved to services.
There was a problem hiding this comment.
We need IBuilder.Properties... I'll file an issue to discuss that in http abstractions
|
@loudej @davidfowl Can we try to get this reviewed today so it doesn't just sit here next week while I'm OOF? |
|
Can you point out major differences from the katana middleware? |
|
The primary differences are in FacebookAuthenticationMiddleware
Misc:
|
| { | ||
| internal static class Constants | ||
| { | ||
| public const string DefaultAuthenticationType = "Facebook"; |
There was a problem hiding this comment.
Some of the katana middlewares expose something like OpenIdAuthenticationDefaults.AuthenticationType, WsFederationdefaults.Authentication type. Do we plan to consolidate it now in vnext? In other words do we want a FacebookAuthenticationDefaults.AuthenticationType?
|
Updated |
| IDataProtectionProvider dataProtectionProvider, | ||
| ILoggerFactory loggerFactory, | ||
| IServiceProvider services, | ||
| FacebookAuthenticationOptions options) |
There was a problem hiding this comment.
I wonder - with the vNext IOptionsAccessor<TOptions> would we change how that last object could be passed in? Don't need to change in this PR, but something to consider
|
|
|
Updated to use IBuilder.Properties. |
Depends on aspnet/HttpAbstractions#113
TODO: CoreCLR WinHttpHandler does not yet support custom server cert validation.