-
Notifications
You must be signed in to change notification settings - Fork 586
ChallengeContext will be null with [Authorize] attribute #137
Conversation
OpenIdConnect set Ticket.Principal, get identity from there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this duplication needs to be resolved inside of AuthTicket, we don't want every consumer to have to check both properties.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OIDC sets the Principal property.
Since changes w.r.t. that property are still in the early development, I agree to change OIDC until we have a comprehensive fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, I just noticed this. No no no no no. You can't just slap a Principal and an Identity property to AuthTicket. This needs reverting before Beta 3 please.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@blowdart - ClaimsPrincipal was introduced in AuthenticationTicket with OIDC - 49e66f0. @blowdart mentioned in a conversation having both Principal and Identity on AuthenticationTicket is going to confuse users. So until we decide on whether it is Principal or Identity to be in AuthenticationTicket he suggested to remove the Principal property from AuthenticationTicket for beta3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brentschmaltz Is there a reason you needed a full blown principal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use _logger.WriteWarning("{0}", redirectUri ?? "null") overload of logger to substitute parameters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We write the same warning in ApplyResponseGrantAsync method in the same file. Just for consistency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
adjust formating of messages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Niggle - why are we embedding error codes again? This isn't 1995 any more. If an error message is not explicit enough to make sense without having an error code then the message is no good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I assumed that was something standard. If it's just something we made up then please remove it.
ChallengeContext will be null with [Authorize] attribute
OpenIdConnect set Ticket.Principal, get identity from there.