在 asp.net-mvc 中，保存用户内容（图像、文件等）时是否有一个好的库或模式可以遵循

发布于 2024-12-01 18:03:17 字数 247 浏览 3 评论 0原文

我的网站有一个管理部分，“作者”可以上传照片库图片等文件，以便稍后包含在我网站的动态内容部分中。我有某些页面，其中 html 本身存储在我的 mySQL 数据库中，用户可以使用 ckeditor 界面编辑内容。

我想看看是否有什么可以利用的东西可以将文件保存到正确的目录并稍后检索它们，或者我应该从头开始编写这一切。另外，寻找经验教训和需要注意的事项（安全等）

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

暮凉 2024-12-08 18:03:17

我会尝试一下。我们拥有的一个应用程序可以执行与我们类似的操作，并且我们做了“推出我们自己的东西”。用户可以通过我们的应用程序界面上传文件（图像、文档等），并且这些文件确实具有用户/公司/角色敏感权限。为了减轻一些安全问题和其他一些原因，我们实施了以下措施。

在 Web 应用程序中，我们创建了一个“Assets”文件夹，用于存储所有用户生成的内容。然后，我们使用子文件夹来帮助分割内容（徽标、文件等）。
在 web.config 中，我们使用以下几行将此文件夹配置为无法从浏览器访问（类似于 App_Data 或 bin 文件夹）（我们这样做是为了确保这些文件都不能直接从浏览器访问）查看更多关于第 4 点）：
```
 ;
<安全>
  <请求过滤>
    <隐藏段>
      <添加段=“资产”/>
    
  
```
文件上传后，我们会将文件的相关信息存储在数据库中（类型、大小、名称、注释）。这还允许我们将文件上的角色和用户安全信息关联起来。
为了检索文件，我们实现了一个具有一组操作的控制器，该控制器获取请求的文件名和用户信息（因为您必须登录）并从资产文件夹返回文件。对于最终用户来说，看起来所有文件都存储在 /Files/Docs/FileID 或类似的目录中，但实际上这只是文件本身的前端“看门人”。如果您未经授权或请求错误文件，此控制器/操作方法将返回 404。对于文件命名，我们只需生成 GUID 并将文件命名为“GUID.relevantExtension”（检查文件是否已存在）

我想为了吸取教训或其他什么，最重要的是您不要直接公开文件，特别是如果用户不共享内容。另外，这可能是个人偏好，如果不小心可能会引发一场战争，我不太喜欢在数据库中存储文件，因为这似乎会导致分页和缓存性能问题（也不是谈论 SQL 2008 文件列）。希望这有帮助！

编辑 - 这样做的另一个想法，从 VS 进行发布时要注意。这些上传的文件不是您的解决方案的一部分，如果您执行删除上传类型发布，您将为您的用户文件打蜡。只是警告一下（去过那里:/）

I'll take a stab at this. An application that we have that does something similar we did and we did the 'roll our own thing'. Users can upload files (images, documents, whatever) through our application interface and these files do have user/company/role sensitive permissions. In order to mitigate a few security concerns and for a few other reasons, we implemented the following.

In the web application, we created an 'Assets' folder that is used to store all of the user generated content. We then use subfolders to help segment the content (logos, files, etc).
In the web.config, we configured this folder to not be accessible from the browser (think like the App_Data or bin folders) with the following lines (We did this to ensure that none of these files could be accessed directly from the browser. See more on point #4):
```
 <system.webServer>
<security>
  <requestFiltering>
    <hiddenSegments>
      <add segment="Assets"/>
    </hiddenSegments>
  </requestFiltering>
</security>
```
Once a file is uploaded, we store the relevant information about the file in database (type, size, name, comments). This also allows us to relate role and user security information on the file.
In order to retrieve the files, we implemented a controller with a set of actions that takes the requested file name and user information (since you have to be logged in) and returns the file from the Assets folder. To the end user, it looks like all files are stored in /Files/Docs/FileID or something similar but in actuality this is just a front-end 'gatekeeper' to the files themselves. This controller/action methods return a 404 if you are not authorized or if you request a bad file. For file naming, we just generate GUIDs and name the file "GUID.relevantExtension" (checking that one doesn't exist already)

I guess for lessons learned or whatnot, the biggest thing is that you do not expose the files directly especially if users are not sharing content. Also, and this is probably personal preference and could start a war if not careful, I am not big on storing files in the database at it seems to cause issues with paging and caching performance (not talking about SQL 2008 File column either). Hope this helps!

EDIT - Another thought on doing this, be aware when doing publishing from VS. These uploaded files are not part of your solution and if you do the Delete the Upload type publishing, you will wax your users files. Just word of caution (been there :/)

回复收藏 0 原文