Drop the `CustomPolicyProvider` sample app?

[guardrex]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

This is WRT the sample app at https://github.com/dotnet/aspnetcore/tree/main/src/Security/samples/CustomPolicyProvider.

On the docs side, we maintain both ...

• Pre .NET 8 version of this sample: https://github.com/dotnet/AspNetCore.Docs.Samples/tree/main/security/authorization/OldStyleAuthRequirements
• .NET 8 or later version that uses IAuthorizationRequirementData: https://github.com/dotnet/AspNetCore.Docs.Samples/tree/main/security/authorization/AuthRequirementsData

I'm updating our coverage to better describe how the sample works and how to demo an age requirement, noting that our article describing the use of IAuthorizationRequirementData and the sample is versioned .NET 8 or later. We're only going to maintain the .NET 7 (or earlier) approach for the code and text shown in the .NET 8 release notes, where I'm also making some small updates.

Since the CustomPolicyProvider sample app uses the older approach but is still being built for each release after .NET 7 here, do you just want to drop it from the engineering repo?

Describe the solution you'd like

Possibly drop the https://github.com/dotnet/aspnetcore/tree/main/src/Security/samples/CustomPolicyProvider sample app from this repo.

Additional context

No response

[MackinnonBuck]

@guardrex, we'd like to keep that sample in our repo because they're useful for debugging as we're making changes to the framework.

However, we're supportive of removing these samples from the docs. Is it fine if we remove the AspNetCore.Docs.Samples versions of these samples without removing the aspnetcore versions?

[guardrex]

@MackinnonBuck ... The problem is that the framework sample uses the older approach ... the pre-.NET 8 approach ... i.e., it doesn't use IAuthorizationRequirementData. It looks like (perhaps) the sample wasn't updated when the framework work when in on #44342.

Per https://learn.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-8.0?view=aspnetcore-9.0#iauthorizationrequirementdata, Rick halfway updated the doc sample to use IAuthorizationRequirementData. He just didn't cut out the older parts, so we had an issue come in on dotnet/AspNetCore.Docs#32595. I was originally going to solve that by cross-linking the framework sample; but when I saw that it didn't use IAuthorizationRequirementData, I updated the doc sample instead and left it linked into the article.

The documentation is fine in it's current coverage, which is live here ...

https://learn.microsoft.com/en-us/aspnet/core/security/authorization/iard?view=aspnetcore-9.0

I didn't call for PU review, as it seemed straight-forward to apply updates and overhaul the article. I think we'll just take reader feedback on that article and see how it goes.

We can close this if you're indeed ok with the framework sample using the non-IAuthorizationRequirementData approach of <.NET 8.

If I missed a sample somewhere here that does use IAuthorizationRequirementData, then the documentation can cross-link it. I don't think it exists tho ...

https://github.com/search?q=repo%3Adotnet%2Faspnetcore%20IAuthorizationRequirementData&type=code

[MackinnonBuck]

Thanks, @guardrex.

While we don't fully understand the problem, on second thought we think it's valuable to keep these docs. We get that it's simpler to enforce a minimum age policy with an IAuthorizationRequirementData, but a policy provider is more flexible. Maybe we just add a note that for the specific scenario of enforcing a minimum age, a policy provider isn't necessary, but when doing something more advanced like determining a policy dynamically by e.g., reading from a database, a policy provider can be helpful.

[guardrex]

I wasn't talking about dropping the article ... I just updated the article. The article is good 👍.

This issue here is asking if you wanted to keep the sample with it's pre-.NET 8 approach, given that what the sample shows isn't the more modern way to approach things. Since you want to keep it, I'll close this.