[AuthZ] Add IRequirementData
Explore allowing an attribute to add requirements
@davidfowl
I went back to just enabling adding requirements via an attribute since that makes it a little simpler to combine as there already are existing ways to specify what authentication, i.e. [Authorize].
Maybe we just need IRequirementData to exist. We don't need RequiresAttribute. I'm thinking the typical use case for this is what we have documented here today. After this change, it would look like this:
internal class MinimumAgeAuthorizeAttribute : AuthorizeAttribute, IRequirementData
{
public MinimumAgeAuthorizeAttribute(int age) => Age = age;
public int Age { get; }
IEnumerable<IAuthorizationRequirement> GetRequirements() => new[] {
new MinimumAgeRequirement(Age)
};
}
Sounds good, but in your example, GetRequirements would be even simpler right, since we don't need to build the policy anymore, it'd just be: new[] { new MinimumAgeRequirement(Age) } without the policy builder
Sounds good, but in your example, GetRequirements would be even simpler right, since we don't need to build the policy anymore, it'd just be: new[] { new MinimumAgeRequirement(Age) } without the policy builder
Oops, fixed.
Okay updated, pretty tiny change that actually enables a lot
Note: IRequirementData does trigger authorization by itself, so it doesn't require an [Authorize] attribute or IAuthorizeData to have an effect
Lets do API review, file an issue and lets get this checked in and marked for blogging 😄 cc @adityamandaleeka
@HaoK, this change will be considered for inclusion in the blog post for the release it'll ship in. Nice work!
Please ensure that the original comment in this thread contains a clear explanation of what the change does, why it's important (what problem does it solve?), and, if relevant, include things like code samples and/or performance numbers.
This content may not be exactly what goes into the blog post, but it will help the team putting together the announcement.
Thanks!
May I suggest naming it IAuthorizationRequirementData in case you'd come with a similar design for other areas like CORS in the future?
Sounds reasonable I'll update the design issue with the suggested new name, but I won't update this PR until after the api review has been done in case of other feedback