RC1 Port: Add FailureReasons (#35425)#35529
Conversation
|
@wtgodbe so there is modification to unshipped APIs in this PR, but I don't think I've modified any public shipped apis, this was just a cherry pick of a main PR, so I'm not sure how to resolve the code check failure, any ideas? |
|
@BrennanConroy fixed that check yesterday, it should pass now |
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
Kahbazi
left a comment
There was a problem hiding this comment.
Is it possible to create the failure list only if it's needed?
This comment has been minimized.
This comment has been minimized.
Co-authored-by: Kahbazi <akahbazi@gmail.com>
…t.cs Co-authored-by: Kahbazi <akahbazi@gmail.com>
|
Ah! failed again! I hope this would fix it! @Tratcher #35529 (comment) |
…t.cs Co-authored-by: Kahbazi <akahbazi@gmail.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@wtgodbe ready to merge. |
|
Resolved as part of #35632. |
|
Do we need to apply the changes from this PR to main? |
I'm on it! |
|
Hi @Kahbazi. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context. |
Backport of #35425
Customer Impact
There currently is no way to flow more detailed authorization failures from the IAuthorizationHandler to consumers that are responsible for displaying authorization errors. This change allows handlers to flow custom messages and state
Testing
Automated tests and a new sample demonstrating the usage
Risk
Low