【发布时间】：2015-08-25 16:43:10
【问题描述】：
webContentLink 应该是指向由 fileResource 表示的文件的直接链接。
让我们首先忽略这样一个事实，即链接实际上总是以 302 指向生成的 downloadUrl（它的生命周期非常有限）进行响应。
我了解webContentLink 指向的资源使用基于 cookie 的身份验证，并且 CORS 会带来安全风险，但是文档明确指出，当相关文件公开时（显然）不需要身份验证。
因此，对于文件公开可用的情况，我不明白为什么不支持 CORS。
是否存在一些我没有意识到的与此相关的安全风险？漏洞？在使用或不使用Access-Control-Allow-Origin 进行响应之前检查文件的权限是否被认为工作量太大。
附带说明，使用服务器端代理获取 302 位置指向的 downloadUrl 会生成支持 CORS 的资源。
【问题讨论】：
-
文件需要下载到用户端还是服务器端？如果它在拥有浏览器的用户中使用 webContentLink 就足够了吗？如果您想对文件执行特定操作并且您的应用程序已经在使用 api（我猜这就是您获得该 url 的方式），您可以使用 DownloadUrl（而不是 webContentLink）发出经过身份验证的获取请求（是的，即使文件是公开的，请求必须经过身份验证）才能获取文件。
-
该链接意味着在获取链接后无限期使用，因此获取
downloadUrl并不好，因为它只有 8 小时的生命周期。不，当指向的文件公开可用时不需要身份验证，问题是 webContentLink 不支持 CORS，因此无法在用户浏览器中访问。 -
如果文件是公开的，您可以在不经过身份验证的情况下调用 files.get 等 API 方法，但是要调用 DownloadUrl，您确实需要经过身份验证。我还发现，在未经身份验证的情况下使用 files.get 时获得的 DownloadUrl 不起作用，如果您进行相同的调用进行身份验证，则该 URL 是不同的，现在它可以工作了。正如您所提到的，如果您需要永久拥有该链接，则此 Url 将无用。你能解释一下你的用例吗？您是否在您的网站上显示该文件？你如何向用户展示文件信息？你在做链接吗？
-
API 不是一个选项，因为它始终需要 OAuth 2.0 身份验证。问题不在于实现该功能，我找到了解决问题中提到的限制的方法。提出这个问题的原因是让 Google 员工回答该行为是错误还是有意为之，同时也让人们了解可能存在的安全问题，从而证明缺乏 CORS 支持是合理的。
-
哦，好的，没关系。如果您有解决方案，您能否发布给您错误的原始实现以及您如何解决它？也许其他用户正在做同样的事情并且可以与这个问题相关，或者甚至为了测试更好地重现他的问题的步骤。
标签： google-api google-drive-api cors