Deprecate the IAuthenticationHandler property #863
Conversation
| @@ -9,6 +10,7 @@ public interface IHttpAuthenticationFeature | |||
| { | |||
| ClaimsPrincipal User { get; set; } | |||
|
|
|||
| [Obsolete("This is obsolete and will be removed in a future version. The recommended alternative is to use Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions. See https://go.microsoft.com/fwlink/?linkid=845470.")] | |||
There was a problem hiding this comment.
Drop "The recommended alternative is to use Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions."? It's not a direct replacement for this API.
There was a problem hiding this comment.
Looks fine, how far do we want to go down the obsolete path? For preview 2 we just deprecated the most common httpContext.Authentication. Do we want to deprecate all of the classes/properties for RTM? Its a bit redundant since there is no way for them to have used any of the other stuff without having a context.Authentication call so...
|
@HaoK Just the entry points. |
|
We should at least do AuthenticationManager. That would get any code that was accepting it as a parameter. |
|
@Tratcher just the class and not all of the methods right? |
|
At least the class. And at that point why not do the methods too? |
|
How would they ever call these methods without going through context.Authentication? |
|
Yes someone would have to call context.Authentication before calling this method, but that may not even be in the same project as a method accepting AuthenticationManager. |
|
So in that usage it would be enough to have it on the class then right? They'd only have access to the methods via context.Authentication or an explicit type reference |
|
Right, but at that point why not just do all the methods? It's just some copy-paste? |
|
I'm just trying to avoid the viral spread of obsolete/pragmas, if the methods don't spread pragamas sure... |
#861