Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Host environment path #590

Open
nickalbrecht opened this issue Mar 21, 2023 · 4 comments
Open

Host environment path #590

nickalbrecht opened this issue Mar 21, 2023 · 4 comments
Labels
bug Issues describing a bug or pull requests fixing a bug.

Comments

@nickalbrecht
Copy link

nickalbrecht commented Mar 21, 2023

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 nickalbrecht added the bug Issues describing a bug or pull requests fixing a bug. label Mar 21, 2023
@nickalbrecht
Copy link
Author

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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

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": "[email protected]",
            "files": [
                "jquery.min.js",
                "jquery.js",
                "jquery.slim.min.js",
                "jquery.slim.js"
            ],
            "destination": "wwwroot/vendor/jquery"
        }
    ]
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issues describing a bug or pull requests fixing a bug.
Projects
None yet
Development

No branches or pull requests

2 participants