Blazor Static Assets - don't serve directories prefixed with "."

Describe the bug

The StaticWebAssetsLoader assumes all paths in the manifest are valid for serving up:

https://github.com/dotnet/aspnetcore/blob/1480b998660d2f77d0605376eefab6a83474ce07/src/Hosting/Hosting/src/StaticWebAssets/StaticWebAssetsLoader.cs#L43

So for example, it will serve from a base path like “.apps/foo”

However the standard PhysicalFileProvider (which comes into play after a publish and the assets are copied to the output dir) will not serve up content from directories in a folder prefixed with a dot - e.g “.apps/foo”

Go to a client wasm project and set:

 <StaticWebAssetBasePath>apps/.foo</StaticWebAssetBasePath>

Also make sure you set the basePath element in index.html accordingly to “apps/.foo”

Note: the “.” in the path

Then run the host (in Development environment) and browse to “apps/.foo” - It will successfully serve up the app - thanks to the Static Web Assets file provider.

However, when youdotnet publish the application and run it, it doesn’t serve up any files from that directory at all, as then its the PhysicalFileProvider coming into play and by default it won’t serve content from “.” prefixed folders.

This technique of outputting static assets to a “.” hidden folder is desirable when wanting to hide the static asset from being served up by default, so I can then “opt in” to serving the static assets to particular tenants who should have access by setting up my own file provider at runtime pointing to that “private” directory. If I allow all apps to be served up by default (by not putting them in a path under webroot that is prefixed with a “.”), it means all tenants have access to all apps, and I can’t control which tenants see which static content using my own logic. I am aware I could also do custom msbuild targets so that when the content is published it goes somewhere outside of the webroot directory, but this won’t be constistent with the development experience and will involve more work than the fix I am proposing here.

If “StaticWebAssetsLoader.cs” can be fixed to honor the “.” mechanism for ignoring paths (not setting up file provider) for static asset base paths that contain “.” prefixes, then this will make development environment behaviour consistent with production, and provide a feature where by some content can now be hidden from being served up by static files automatically, giving the application a chance to implement it’s more complex requirements over the serving of that content).

For additional background, I have multiple SPA’s referenced from my host, and all SPA’s are relevant to my app, but not all SPA’s should be accessible to all tenants of my app, and the current static files stuff assumes that they should be (in Development environments). Dotnet publish “kind of” also assumes that they should be by virtue of copying all static assets to the “wwwroot” directory of the published application. However by virtue of the PhsyicalFileProvider behaviour for ignoring folders prefixed with “.” and setting StaticWebAssetBasePath to a path with a dot prefix, I can get the behaviour I want and keep those assets “Hidden” by default. However the static assets file provider comes into play on Development environments and doesn’t obey the “.” rule. I grant that the nature of this problem isn’t critical because it only impacts behaviour on development environments - however it “would be nice” if this was consistent with the behaviour we will ultimately see in production / staging environments as it will allow us to verify things adequately before deploying onwards to those environments.

For further background see #20580

Note: I’ve logged this as a bug but it depends on your view point, it’s a bug in that it’s a difference in behaviour from PhysicalFileProvider which is used after a dotnet publish.

[javiercn]

@dazinator there is no property for that, you would need to write your own target.

[javiercn]

As per the comment here the feature is working as expected