Host environment path

[nickalbrecht]

Describe the bug

Just found this and was trying out the resource integrity helper in a local dev environment, but was getting an error about the local file not being found.
I did some digging into the source but wasn't sure if this was a bug or if I'm using it wrong. Assuming the intent is to fallback to the local version of a resource if its hash doesn't match that of the CDN, shouldn't the logic in the GetSubresourceIntegrityFromContentFile() be combining the relative path with WebRootPath, not ContentRootPath?

Steps to reproduce

I was trying this with jQuery as a test and was using the below tag

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.4/jquery.min.js"
        asp-subresource-integrity-src="~/js/jquery/jquery.min.js"
        asp-fallback-src="~/js/jquery/jquery.min.js" asp-append-version="true"
        asp-fallback-test="window.jQuery"></script>

Expected behaviour

Was expecting it to output the script tag with a SRI hash

[nickalbrecht]

Though this led me to also wonder why it couldn't use asp-fallback-src from the ScriptTagHelper, rather than having to define the source twice?

[nickalbrecht]

Disregard the last bit about asp-fallback-src. Using the same attribute as another tag helper makes it impossible to use one and not the other as far as I can tell. Which is problematic. I can handle the redundancy issue of declaring a value on multiple attributes if I means I a can selectively use my tag helpers better. The RootPath is still a thing though.

[RehanSaeed]

I haven't used tag helpers in a while so not sure when this might have broken. Interested in submitting a small PR to fix this?

[nickalbrecht]

It's literally just the one word, here.

https://github.com/Dotnet-Boxed/Framework/blob/c626308b0512144226686545487ebeb7b7466d57/Source/Boxed.AspNetCore.TagHelpers/SubresourceIntegrityTagHelper.cs#LL242C49-L242C49

The ContentRootPath is the root folder of the website when you publish, but nothing gets served from that path. That's just the where the binaries live. All of the web assets sit in the wwwroot folder (WebRootPath) and are available as a result of setting up static file handling. Where, assuming the idea is to serve from that folder should the CDN version fail the integrity check, I presume is where you'd have the local copies sitting. Otherwise your site just refused to load the CDN copy, and it stays broken. I'm assuming that's where people would typically put the client side assets anyway; since, if you're going to deploy them with your app to dynamically generate the integrity hash at runtime, you might as well also make them servable as well to act as your failover.

In my case, I'm using Nuget package Microsoft.Web.LibraryManager.Build to copy them locally as part of the build. Maybe others are doing it differently if they are doing SPAs or the like, I'm not sure.

{
  //my corresponding entry in ./libman.json
  "defaultProvider": "cdnjs",
    "libraries": [        
        {
            "library": "jquery@3.6.4",
            "files": [
                "jquery.min.js",
                "jquery.js",
                "jquery.slim.min.js",
                "jquery.slim.js"
            ],
            "destination": "wwwroot/vendor/jquery"
        }
    ]
}