通过互联网共享文件 - WebDAV / SMB / FTP
我们正在开发一个基于网络的应用程序，它提供用户案例文件的存储库。希望用户能够通过具有完整读写功能的网络浏览器访问这些内容。
对于我们的早期系统，该系统托管在带有 Windows 客户端的本地 Linux 服务器上，我们能够共享文件夹并通过 \\server\share_name\file.doc 类型链接访问它。如果这些类型的链接包含在网页（在 Internet Explorer 中）中，并且单击在 MS Word 中打开的文件，并且可以直接保存到共享文件夹中。然而，这些类型的链接仅适用于 IE - 不适用于 FF 或 Chrome
现在，在我们的下一代系统中转向基于互联网的解决方案，我们需要类似的功能。
我们正在尝试使用 WebDAV（或 FTP/SFTP）共享并将每台客户端计算机上的本地驱动器映射到它以提供类似的功能。不过，这可能不适用于带有 \\server\share_name... 类型链接的 FF 或 Chrome。我们已经进行了简短的测试，文件打开后，file:// 链接不提供写入功能。
作为最后的手段，我们将能够使用手动文件上传对话框，但这并不理想，并且需要额外的最终用户培训。
有没有人在这个领域有类似的经验以及任何可能的解决方案/最佳实践。
We are developing a web based application which provides a repository of users case files. Would like the user to be able to access these from their web browser with full read write capability.
For an earlier generation of our system, which was hosted on a local Linux server with Windows clients we were able to share out a folder and access it with \\server\share_name\file.doc type links. If these type of links were included in web pages (in internet explorer) and clicked on the file opened in MS Word and was savable directly into the shared folder. These type of links however only worked in IE - not FF or Chrome
Moving now to an internet based solution in our next generation of the system, we require similar functionality.
We are toying with the idea of having a WebDAV (or FTP/SFTP) share and mapping a local drive on each client machine to it to provide similar functionality. This though will probably not work well with FF or Chrome with \\server\share_name... type links. We have done brief testing and file:// links do not provide write capability once the file is opened.
As a last resort we will be able to use manual file upload dialogs, but this is not ideal and would entail additional end user training.
Has anyone any similar experience in this field and any possible solutions / best practice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当您将远程资源映射为本地驱动器时，对于浏览器来说，这将成为本地驱动器。并且浏览器对本地文件系统的访问权限有限。现在，当您向浏览器提供链接时，浏览器的默认行为是下载链接后面的资源，然后让本地应用程序处理它。浏览器只是不知道如何以不同的方式在本地打开远程资源。
解决方案是让浏览器下载某些内容（某种链接文件），并让一些本地帮助程序模块（外部应用程序或浏览器插件）打开此链接文件并在本地打开此链接文件中指定的位置。由于这将是客户端帮助程序模块，因此它将能够与客户端系统交互并知道如何打开提供的链接。鉴于每个系统上的虚拟驱动器号可能不同（如果将磁盘安装到驱动器号），帮助程序模块需要解析链接以指向正确的本地驱动器。如果您创建隐藏的虚拟驱动器（我们的虚拟存储产品允许您执行此操作），则链接将类似于“\SomeFancyNameUniqueToYourApp\Path\To\File.ext”，并且不需要解析。大多数应用程序都能很好地处理这种类型的路径。
我不确定，但浏览器可能会在不需要帮助程序模块的情况下打开 Windows .lnk 文件，并且使用隐藏的虚拟驱动器，您可以在服务器上生成 LNK 文件并让浏览器在本地打开它。但这只是一个猜测。我敢打赌，无论如何你都需要一个辅助模块。
When you map remote resource as a local drive, for a browser this becomes a local drive. And browsers have only limited access to the local file system. Now when you provide a link to the browser, the browser's default behavior is to download the resource behind the link, and then let the local application process it. The browser just doesn't know how to open the remote resource locally in a different manner.
The solution would be to let the browser download something (some kind of link file) and have some local helper module (external application or browser plugin) open this link file and open the location, specified in this link file, locally. As this would be a client-side helper module, it will be able to interact with the client system and will know how to open the provided link. Given that the virtual drive letter can be different on each system (if you mount the disk to the drive letter), the helper module would need to resolve the link to point to the correct local drive. If you create a hidden virtual drive (our virtual storage products let you do this), then a link would look like "\SomeFancyNameUniqueToYourApp\Path\To\File.ext" and no resolving would be necessary. And most applications handle this type of paths fine.
I don't know for sure, but it's possible that browsers will open Windows .lnk files without a need in helper module, and with hidden virtual drive you could generate an LNK file on the server and have the browser open it locally. But this is just a guess. My bet is that you will need a helper module anyway.
ftp://username:password@hostname/ 类型的链接应该可以工作，并且 MS 应用程序在处理它们方面做得越来越好。但仍然不是 100%
ftp://username:password@hostname/ type links should work, and MS apps are getting better at handling them. still not 100% though
尝试 SMEStorage.com。它们使您能够映射本地 WebDav 和 FTP 服务器，并使用 Linux、Mac 或 Windows 上的云驱动器以及移动设备（iOS、Android、BlackBerry 和 Windows Phone 7）访问文件。您可以获得每个文件的唯一文件链接，并且还可以在链接过期时安全地进行文件共享。
Try SMEStorage.com. They enable you to map local WebDav and FTP servers and access files using a Cloud Drive on Linux, Mac or Windows, and also from mobile devices (iOS, Android, BlackBerry and Windows Phone 7). You can get unique file links for each file and also secure file sharing in which the links expire.