Skip to content

Conversation

@khellang
Copy link
Contributor

I think this should cover them all 😄

Closes #97

ClaimActions.MapJsonKey("urn:yahoo:profile", "profileUrl");
ClaimActions.MapJsonKey("urn:yahoo:profileimage", "imageUrl");
ClaimActions.MapJsonKey(YahooClaimTypes.FamilyName, "familyName");
ClaimActions.MapJsonKey(YahooClaimTypes.GivenName, "givenName");
Copy link
Contributor Author

@khellang khellang Feb 15, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason a lot of these are using custom claim types instead of the built-in ones, like ClaimTypes.GivenName, ClaimTypes.Surname, etc.? Same in a lot of other places.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most likely an oversight (most of the aspnet-contrib providers have been written by different contributors, who may not be super familiar with all the built-in claim names).

FWIW, I try to avoid using the "legacy" WS-Fed claims as much as possible (because they're super long and make cookies/tokens bigger) but the MSFT OAuth2 providers use them when it's possible so we use them too for consistency.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, so as long as there's no transformations for them anywhere, it doesn't really matter? Or, it might even be better to use custom claim types because of the smaller size?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's go with the built-in ClaimTypes when we have a good constant for these claims. Consistency always wins, I guess.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't want to change any claim types in this PR, as it would be a breaking change. Should we open an issue for later?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Breaking changes are kinda acceptable as we're still in RC. But yeah, separate PR if you prefer 👍

@kevinchalet
Copy link
Member

@khellang FYI, we use a little different pattern in the other aspnet-contrib projects. E.g:

public static class GitHubAuthenticationConstants
{
    public static class Claims
    {
        public const string Name = "name";
    }
}

Do you strongly prefer your pattern, or would adopting the one I suggest be acceptable for ya?

@khellang
Copy link
Contributor Author

Do you strongly prefer your pattern, or would adopting the one I suggest be acceptable for ya?

It's your project. I'm just following orders 😉It'll have to be another day, cause it's bedtime here 😴

@kevinchalet
Copy link
Member

It's your project. I'm just following orders

Let's go with the nested classes pattern, then (I like when it's consistent).

It'll have to be another day, cause it's bedtime here sleeping

Sure, no hurry.

Thanks for this PR! 👏

@kevinchalet kevinchalet self-assigned this Feb 16, 2018
@kevinchalet kevinchalet added this to the 2.0.0 milestone Feb 16, 2018
{
public static class Claims
{
public const string Emailverified = "urn:autodesk:emailverified";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EmailVerified?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, thanks!

@kevinchalet
Copy link
Member

Merged, thanks! 4f46357

@kevinchalet kevinchalet closed this Jun 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

3 participants