【问题标题】:Serving and Verifying network share images in Asp.Net Core 3.1 Web Application (Razor Pages)在 Asp.Net Core 3.1 Web 应用程序(Razor 页面)中提供和验证网络共享图像
【发布时间】:2021-01-06 18:58:31
【问题描述】:

我有一个网络文件共享,其中包含来自各种应用程序的图像。在一个较旧的应用程序中,我们只是在 IIS 中创建了一个虚拟目录并使用 Server.MapPath(...) 来获取正确的路径。这在 Asp.Net Core 3.1 中不再存在。

所以我在我的项目中添加了一个 /Data 文件夹,然后添加了一个额外的 app.UseStaticFiles 实例以将 /Data 文件夹映射到网络共享路径。

这是Startup.csConfigure(...)函数的代码:

        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            . . .

            // serves static js/css/whatever files from /wwwroot
            app.UseStaticFiles();

            // serves static image files from /Data
            app.UseStaticFiles(new StaticFileOptions
            {
                FileProvider = new PhysicalFileProvider(Path.Combine(env.ContentRootPath, "Data")),
                RequestPath = "//networkdriveshare/pathToImages"
            });

            app.UseCookiePolicy();
            app.UseRouting();            
            app.UseAuthorization();            
            app.UseSession();
            
            app.UseEndpoints(endpoints =>
            {
                endpoints.MapRazorPages();
            });
        }

问题

我需要能够在显示之前确定网络共享上是否存在物理图像。

什么有效

我可以很好地使用 Razor 页面标记中的标签显示图像,并确认它来自网络共享,如下所示:

    <img src="~/Data/PathInNetworkDrive/placeholder.jpg" alt="placholder test" class="card-img" />

什么不起作用

我需要能够在主页后面的 C# 代码中确定图像文件是否物理地存在于网络共享中。

当我知道那里有数千个文件时,我尝试过的所有操作都会出错,或者只是找不到文件。

这不是安全问题,至少我不认为这是因为我能够从上述 Razor 页面标记中获取图像。

我的尝试

我尝试过使用环境:var storagePhoto = _env.ContentRootPath 结合 '/Data' 文件夹和简单的代码:

        // finds nothing of course, ever
        var storagePhoto = Path.Combine(_env.ContentRootPath, "Data");
        if (System.IO.File.Exists(storagePhoto))
            // found
        else
            // not found

尝试在 Startup.cs 中添加 File Provider,然后在 razor 页面中注入:

    // Startup.cs
    var imagesProvider = new PhysicalFileProvider(Path.Combine(_env.ContentRootPath, "Data"));
    var compositeProvider = new CompositeFileProvider(imagesProvider);

    services.AddSingleton<IFileProvider>(compositeProvider);

    // Index.cshtml.cs
    public class IndexModel : PageModel
    {
        private readonly IFileProvider _fileProvider;
        private readonly ILogger<IndexModel> _logger;
        private IWebHostEnvironment _env;
        ...


        public IndexModel(ILogger<IndexModel> logger,
            IFileProvider fileProvider,
            IWebHostEnvironment env)
        {
            _logger = logger;
            _env = env;
            _fileProvider = fileProvider;
        }

        // blows up on 'GetDirectoryContents' just displays the path to /Data in the error message
        public IActionResult OnGet()
        {
            try
            {
                var contents = _fileProvider.GetDirectoryContents(string.Empty);
                //var filePath = Path.Combine("wwwroot", "js", "site.js");
                //var fileInfo = provider.GetFileInfo(filePath);
            }
            catch (Exception ext)
            {
                Console.WriteLine($"{ext.Message}");
            }        
        }
        ...
    }

欢迎任何帮助

【问题讨论】:

  • 定义“我尝试过的一切”。您具体尝试了什么?
  • 添加了我尝试过的内容,我没有所有内容的代码记录,但我在废品文件中拥有的内容是有问题的。在这一点上我可以添加的最好的
  • _fileProvider.GetDirectoryContents(string.Empty); 究竟返回了什么?
  • 你不能这样称呼System.IO.File.Exists()。对于File.Exists(),您必须使用//networkdriveshare/pathToImages。 System.IO 不会使用您的提供程序。
  • @mxmissile _fileProvider.GetDirectoryContents(string.Empty); 返回我在 Startup.cs 中映射到的目录/文件列表

标签: c# razor-pages asp.net-core-3.1 static-files


【解决方案1】:

回答

一旦我更正了网络共享的路径,解决了查找照片是否存在的问题 - 结果我通过修改服务器上有效但错误的配置犯了一个错误。本来应该是 \\\\server\\folder 的时候是 \\server\folder - 愚蠢的错误。

其次,我错误地配置了额外的app.UseStaticFiles 函数,是我误读了一个示例(是的另一个错误),这是应该的:

            app.UseStaticFiles(new StaticFileOptions
            {
                FileProvider = new PhysicalFileProvider("\\\\server\\folder"),
                RequestPath = "/Data"
            });

我最初的问题中的路径是作为RequestPath 输入的,而不是传递给PhysicalFileProvider(...) 函数。

第三,我不得不从 IIS 应用程序设置中删除 IIS 虚拟目录,因为它阻止了新的静态文件路径。

安全性已经正确,但我们仔细检查了它。

所以,事实证明我走的路是正确的,但我犯了几个错误。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2020-07-09
    • 2019-06-08
    • 1970-01-01
    • 1970-01-01
    • 2020-05-06
    • 1970-01-01
    • 1970-01-01
    • 2020-06-06
    相关资源
    最近更新 更多