用户在云端硬盘中断开应用会导致 FILE 范围内的数据丢失 [英] User disconnecting app in Drive causes loss of data under FILE scope

问题描述

我曾多次遇到此问题，但始终无法将其归咎于 GDAA 的 延迟、我的错误代码等...我终于想出了一个可以安全重现它的场景，所以我想问问 知道的人这是否是一项功能我不明白或一个普通的错误.如果是后者，请指出我可以唠叨的地方.

I've run into this issue a few times, but could never point my finger on it, attributing it to GDAA's latency, my buggy code, etc... I finally managed to come up with a scenario where I can safely reproduce it, so I would like to ask people who know if it is a feature I don' understand or a plain bug. If latter is the case, please point me to the place where I can nag about it.

为简单起见，我将在 REST API 的背景上讨论它.

I will discuss it on the REST API's background for simplicity.

1/让我们有一个 Drive API 在 DRIVE_FILE 范围内运行的经过身份验证的应用

1/ Let's have a Drive API authenticated app that runs under DRIVE_FILE scope

com.google.api.services.drive.Drive svc = 
  new Drive.Builder(
    AndroidHttp.newCompatibleTransport(), 
    new GsonFactory(),
    GoogleAccountCredential
    .usingOAuth2( context, Collections.singletonList(DriveScopes.DRIVE_FILE))
  ).build();

2/在 Google 驱动器中创建一个文件(文件/文件夹)

2/ create a file (files/folders) in Google drive using

svc.files().insert([METADATA], [CONTENT]).execute();

3/搜索您创建的对象

svc.files().list().setQ([QUERY]).setFields([FIELDS]).execute();

当应用程序运行时，用户会执行通常的Account-Pick/Drive-Authorize 例程，一切都按预期工作.文件被创建，可见，可以找到......直到用户通过

When the app is run, user goes through the usual Account-Pick / Drive-Authorize routine and everything works as expected. Files are created, visible, can be found ... until a user revokes the authorization by means of

设置 > 管理应用 > 断开与云端硬盘的连接

Settings > Manage Apps > Disconnect From Drive

在 drive.google.com 中.

之后，如果 Android 应用重新启动(并重新授权)，则在撤销之前创建的所有对象均不可见.

After that, if the Android app is restarted (and re-authorized), none of the objects created prior the revocation is visible.

这可能是设计使然，我不知道.如果是这种情况，我找不到 Android 应用程序如何访问它之前创建的任何内容的方法.我当然可以创建另一个具有 DRIVE 范围的维护"应用程序来解决这个问题，但是......

It may be by design, I don't know. If this is the case, I can't find a way how the Android app can get to anything it created before. I could certainly create another 'maintenance' app with DRIVE scope to fix this, but...

现在，如果是 GDAA，情况会变得更糟.不仅 GDAA 没有 DRIVE 范围来修复它，而且如果执行相同的步骤序列并且应用程序在撤销后立即创建文件/文件夹，GDAA 不会抱怨，但根本不会创建文件/文件夹.过了一会儿(几分钟)，重新授权弹出，但是，同时创建的文件无处可寻，撤销之前的所有内容也丢失给(创建者)应用程序(它肯定是可见的显然具有 DRIVE 范围的 Web 应用程序).

Now, in case of GDAA, it gets even worse. Not only GDAA does not have the DRIVE scope to fix it, but if the same sequence of steps is done and the app creates a file/folder immediately after revocation, GDAA does not complain, but the file/folder is not created at all. After a while (minutes), the re-authorization pops-up, but still, the files created meanwhile are nowhere to be found and everything pre-dating the revocation is lost to the (creator) app as well (it certainly is visible in the web app that obviously has DRIVE like scope).

感谢您的耐心等待.

推荐答案

第一个问题是:

1. 用户通过以下方式撤销授权:设置 > 管理应用程序 > 断开与云端硬盘的连接
2. 然后重新授权该应用程序
3. 已授权此应用查看 DRIVE_FILE 范围内的文件.

这是 REST 和 Android API 的预期行为.

This is the expected behavior of the REST and Android APIs.

我们认为用户不会直观地期望所有以前授权的文件都被重新授权.用户可能不记得之前授权的文件，通知用户这些文件将再次被授权可能会引起混淆.

We don't think users would intuitively expect all previously authorized files to be re-authorized. The user may not remember the files that were previously authorized, and informing users that these files are going to be authorized again will likely cause confusion.

第二个问题是 GDAA 在这种情况下创建文件夹的行为.我们目前不支持使用 CompletionEvents 来创建文件夹，但我们将对此进行研究.

The second issue is GDAA's behavior for folder creation in this situation. We don't currently support CompletionEvents for folder creations, but this is something we'll look into.

这篇关于用户在云端硬盘中断开应用会导致 FILE 范围内的数据丢失的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！