【问题标题】:Chrome File Browser - access full pathChrome 文件浏览器 - 访问完整路径
【发布时间】:2019-06-11 13:58:56
【问题描述】:

我了解,出于安全原因,当我在文件输入字段中通过 FileBrowser 选择时,浏览器不允许我访问文件的完整路径。

不过,我仍然面临需要此功能的问题。也许有人可以提供一个替代解决方案,我不必重新发明任何轮子。

情况如下。

  • 后端和操作用户都可以访问同一个文件系统。
  • 用户必须选择一个或多个文件位置并通知后端。
  • 然后后端会安排一个任务。
  • 同时,用户可能会更改文件内容,但位置将保持不变。
  • 用户浏览器在我们的控制之下。因此,如果需要,我们可以使用扩展。

问题

  • 是否有任何 Chrome 选项可以绕过安全屏障并允许我访问完整路径?
  • 是否有任何有用的 Chrome 扩展程序?
  • 是否有任何已知的替代解决方案或“最佳实践”建议解决此问题?

【问题讨论】:

  • 回答您的问题:否。否。是:让后端显示从 FS 读取的文件列表,以便后端知道完整路径。让用户通过复选框或单击链接而不是输入 type=file 元素进行选择。
  • 这也是我目前的结论。我们已经根据您的建议设计了一个类似的解决方案。但希望有另一种解决方案,我们可以重用用户熟悉的系统文件浏览器。在后端进一步列出文件会增加权限处理的负担。

标签: angular html google-chrome go


【解决方案1】:

我不明白你为什么要重复使用<input type="file">如何你会使用系统文件浏览器来做到这一点。

如果您只是列出目录中可用的文件,然后根据该信息执行操作,您的问题陈述将更容易解决。

package main

import (
    "fmt"
    "io/ioutil"
    "log"
    "net/http"
    "net/url"
)

func main() {
    r := http.NewServeMux()

    r.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        files, err := ioutil.ReadDir(".")
        if err != nil {
            log.Fatal(err)
        }

        out := "<ul>"
        for _, f := range files {
            v := url.Values{}
            v.Add("file", f.Name())
            out += fmt.Sprintf(`<li><a href="/do?%s">%s</a></li>`, v.Encode(), f.Name())
        }
        out += "</ul>"

        w.Header().Set("Content-Type", "text/html")
        fmt.Fprintf(w, out)
    })

    r.HandleFunc("/do", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, r.URL.Query().Get("file"))
    })

    server := &http.Server{
        Addr:    ":8080",
        Handler: r,
    }

    if err := server.ListenAndServe(); err != nil {
        log.Fatal(err)
    }
}

https://play.golang.org/p/bSgm4nAUUYg

注意:此代码不是生产安全的。您必须担心人们可能会访问您所在的.. 上方的目录,以及共享服务器信息带来的各种有趣的东西。但是,它只是为了帮助您入门。

然后,您不必担心浏览器传递给您的内容,您完全可以控制。

【讨论】:

  • 有两个原因。第一:人们已经熟悉原生文件系统。他们在浏览时很容易识别位置。第二:权限控制。本机文件系统浏览器不允许用户输入他无权查看的文件夹。在后端,我们必须根据用户权限过滤文件夹。由于当前的设置,这不是一件容易解决的任务。
  • 这两点最终都违背了规律。如果用户与运行它的服务器位于同一文件系统上,您始终可以通过以用户身份运行 go 进程来列出只有用户有权访问的文件,该用户将无法访问他们无法访问的内容,以实现你正在寻找的东西。从用户的角度来看,他们习惯了原生文件系统,他们也习惯了 Web 文件系统。看看 OneDrive、Google Drive、iCloud 等。
  • 后端在 docker 容器内运行,据我所知,每个用户的用户 ID 和组根本不存在。文件系统的不同部分安装到该容器中。还涉及到 Kerberos。如果您知道如何在这些情况下为用户列出文件,请随时分享,因为我目前正在调查该路径。有问题的特定用户组不熟悉 Web 文件系统。
猜你喜欢
  • 2020-12-31
  • 1970-01-01
  • 2015-01-21
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-03-13
  • 2021-11-28
相关资源
最近更新 更多