Create OwnerDetailsUriTemplateResourceV3 and provider

[donnie-msft]

Bug

Fixes: NuGet/Home#13409

Regression? Last working version:

Description

Note: this resource is not yet consumed by the Client, but will be in #5766

Adds a resource, OwnerDetailsUriTemplateResourceV3, similar to the PackageDetailsUriResourceV3.

• A template must use a Uri scheme of HTTPS and be an Absolute Uri.
• GetUri will replace a template's substring, {owner}, with each Owner returned from the NuGet Search API.
  • Client will not enforce that the template must have this substring. The linked documentation change will suggest that practice.

A new resource provider, OwnerDetailsUriResourceV3Provider, retrieves the resource from the service index, if available.

I've tested in Visual Studio by consuming this resource from package source, https://apidev.nugettest.org/v3/index.json, which @martinrrm has been developing for nuget.org (Thank you! 🙏).

PR Checklist

• PR has a meaningful title

• PR has a linked issue.

• Described changes

• Tests

  • Automated tests added
  • OR
  • Test exception
  • OR
  • N/A

• Documentation

  • Documentation PR or issue filled Add API docs for owners' template resource. docs.microsoft.com-nuget#3282
  • OR
  • N/A

[kartheekp-ms]

We are converting the URI parameter value to a string in the CreateOrNull method, which then calls the IsValidUriTemplate method, passing in that string. I am not sure why we are converting that string again to verify if it is a valid URI. How about just passing the URI object that was passed to the CreateOrNull method instead of creating another URI object here?

Security considerations section in docs suggest that, You can check a URI string for validity by calling the Uri.IsWellFormedOriginalString method. Can this method be used in this case?

[donnie-msft]

I noticed that method as well, but unfortunately, it returns false because of the braces in the URI template provided by the server resource, as shown below.

My suspicion is this is why the PackageDetailsUriResourceV3 does this custom validation, and it's why I copied that for the OwnerDetailsUriTemplateResourceV3 as well.

If you have other suggestions, let me know. I'm a little hesitant to modify the PackageDetailsUriResourceV3 in this PR, but could consider refactoring it as well separately.

[kartheekp-ms]

CreateOrNull method in PackageDetailsUriResourceV3 takes a string as parameter but in this resource the same method has Uri as parameter. Is this could be a reason why we are converting the Uri to string and then string to Uri for validation purposes?

[donnie-msft]

I've reduced some of the validation logic there, have a look and see if that addresses your concern.

[nkolev92]

Minor feedback.

[nkolev92]

You have a Uri type in the method calling this, so you shouldn't need to pass a string.

I'd just all the validations in 1 method and use the Uri type that's already there.

[donnie-msft]

Hm, I was trying not to invent any new validation strategy, as mentioned in #5763 (comment), PackageDetailsUriResourceV3 does this custom validation, and it's why I copied that for the OwnerDetailsUriTemplateResourceV3 as well.

I'll see if I can reduce this validation.

[donnie-msft]

Ok, I don't like this any better than what was there, but now I'm throwing if a null is provided, and now must check for null in the Provider. We don't want providers to throw when they can't find the resource, because it's not required for a package source to implement this resource.

[kartheekp-ms]

I know this PR has already been merged, but I would like to provide some feedback and am happy to discuss it further offline. If my comments are valid, perhaps we could consider opening a follow-up issue.