我目前正在从事一个相当有趣的……项目。我有一个客户希望允许将表单上传（从他们服务器上显示的页面）专门到他们自己的谷歌驱动器帐户。所使用的平台本质上是 LAMP。
单个（预认证）谷歌驱动器帐户。多个其他匿名上传源（用户）。
他们不希望用户被要求拥有自己的谷歌帐户（排除在用户自己的驱动器文件上简单地使用 Picker）。
他们想要某种程度的向后浏览器兼容性，例如 IE8（排除 XHR 使用 HTML5 的文件 API 读取文件数据来形成帖子）。由于某些移动浏览器的潜在兼容性问题，他们不想使用 flash/etc。
什么工作：
- 身份验证（获取刷新令牌，存储，根据需要使用它来获取访问令牌）
- 将文件上传到没有元数据的帐户
- 文件上传的结果被发送到隐藏的 iframe
- 通过 jquery 捕获 iframe 加载事件以至少知道发生了什么事
问题：
- REST API 上传端点不支持 CORS：无法直接访问结果 iframe。（请参阅：使用 JavaScript 对 Google Drive 进行授权）
- 成功上传的返回只是原始 JSON，而不是 JSONP。
- 似乎无法在 googleapis.com 域上通过浏览器打开任何具有适当标头的内容，因此排除了easyXDM和类似的具有跨源解决方法通信 javascript 方法的多 iframe。
- 无法在提交的 POST 中嵌入回调 URL，API 不允许这样做。
- 如果您将 Oauth2 令牌传递给在浏览器中也通过身份验证的用户（假设通过 cookie），则选取器会在尝试上传时显示错误。奇怪的是，您可以显示来自 Oauth2 令牌的匹配帐户的文件，但除了在目标 Oauth2 令牌的帐户与已登录用户匹配的浏览器实例中，任何文件上传都会失败并显示模棱两可的“服务器拒绝”消息。所有文件和文件类型都会发生这种情况，包括在经过身份验证的浏览器实例中工作的文件。我认为这是某种身份验证流程/范围问题。我还没有尝试过深入 Picker 源。
- 所有 javascript Google Drive API 上传示例似乎都依赖于使用 HTML 5 来获取文件数据，因此似乎排除了任何这种性质的事情。上传文件时，除了猜测哪个文件来自哪个用户之外别无他法，因为我们无法从无法访问的 iframe 中的结果中获取文件对象 ID。充其量我们可以做出一个非常粗略的基于时间的猜测，但在并发问题的情况下这是一个糟糕的主意。
- 我们不能为文件设置文件名或任何其他标识符（甚至不是唯一的文件夹），因为 REST API 依赖于通过 JSON 发送的元数据，而不是通过表单字段。所以我们最终在驱动器中得到没有名称/等的文件对象。
- 我们无法使用填充了元数据的服务器端（或通过 jquery/XHR 或 google javascript API 客户端）创建文件，然后使用基于表单的上传对其进行更新，因为更新 API 端点仅适用于 PUT（已测试）。
- 我们无法将文件上传到我们的本地服务器，然后将它们发送到谷歌（代理它们），因为 php ini 被锁定以防止更大的文件上传（并且回到对使用 HTML5 或 flash 施加的限制，因为我们不能块文件/等）。
所有这些都经过研究并在不同程度上进行了尝试。
目前这正在进行中（至少这是学习 API 并了解其局限性的一种有用方式），我将在 Dropbox 上实现类似的东西，但如果有人有任何有用的输入，它会要可爱！
例如，有什么方法可以让它与 Drive 一起使用？我忽略了什么吗？
我也意识到这可能本质上是一个低于预期的用例，所以我并不期待奇迹。我意识到理想的流程是简单地允许用户在必要时上传到他们自己的谷歌驱动器，然后让他们授予对我们的网络应用程序的文件访问权限（通过 Picker 或 API +我们自己的 UI），但这会成为一个问题我们自己的所有用户都必然已经是 google 帐户用户。我知道谷歌显然更希望我们让更多的人与他们注册以实现这一点，但是排除了让人们注册一个谷歌帐户来使用我们的应用程序的可能性（不是出于我们的任何偏见，只是增加了太多步骤和潜在的用户障碍）。如果他们确实有帐户，即使只是让他们登录谷歌也被认为对于基本 LCD 功能功能来说是不需要的，尽管它'