用户断开应用程序在驱动器导致FILE范围内的数据丢失 [英] User disconnecting app in Drive causes loss of data under FILE scope

问题描述

我遇到了这个问题几次，但永远不能指向它，将它归因于 GDAA的< /延迟，我的错误代码等等......我终于设法想出了一个可以安全地重现它的场景，所以我想问问知道它的人是否是一个功能我不明白或一个普通的错误。如果是后者，请将我指向我可以唠叨的地方。

我会在 REST 上讨论它API的简单背景。

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

  com.google.api.services.drive.Drive svc = 
新Drive.Builder（
 AndroidHttp.newCompatibleTransport（），
新的GsonFactory（），
 GoogleAccountCredential 
 .usingOAuth2（上下文，Collections.singletonList（DriveScopes.DRIVE_FILE））
）.build（）; 
  

2 /在Google驱动器中使用 $ b $创建文件（文件/文件夹） b

  svc.files（）。insert（[METADATA]，[CONTENT]）。execute（）; 
  

<3> /搜索您创建的对象

  svc.files（）。list（）。setQ（[QUERY]）。setFields（[FIELDS]）。execute（）; 
  

当应用程序运行时，用户会经历通常的 Account-Pick / Drive-Authorize 例程，一切按预期工作。直到用户通过

撤销授权，文件才被创建，可见，可以找到设置>管理应用程序>断开连接在 drive.google.com 中开车

。

之后，如果Android应用程序重新启动（并重新授权），则在撤销之前创建的对象都不可见。

可能是设计，我不知道。如果是这种情况，我无法找到Android应用程序如何获得它之前创建的任何方式。我当然可以用DRIVE范围创建另一个'维护'应用程序来解决这个问题，但是...

现在，如果 GDAA ，情况会变得更糟。不仅GDAA没有DRIVE范围来修复它，但如果完成了相同的步骤序列并且应用程序在撤销后立即创建文件/文件夹，GDAA不会发出抱怨，但文件/文件夹根本不会创建。经过一段时间（分钟）后，重新授权弹出，但仍然无法找到创建的文件，并且在约会前的所有内容都会丢失给（创建者）应用程序（它当然可以在显然具有像范围的DRIVE的Web应用程序）。

感谢您的耐心等待。 解决方案

第一个问题是：

1. 用户通过以下方式撤消授权：设置>管理应用程序>断开驱动器连接
然后重新授权该应用程序

此应用程序被授权查看DRIVE_FILE作用域的文件已不再授权。 >这是REST和Android API的预期行为。

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

第二个问题是GDAA在这种情况下创建文件夹的行为。我们目前不支持文件夹创建的CompletionEvents，但这是我们将要研究的内容。

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.

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

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/ create a file (files/folders) in Google drive using

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

3/ search for the objects you've created using

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

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

in drive.google.com.

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

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...

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).

Thank you for you patience.

解决方案

The first issue is:

1. A user revokes authorization via: Settings > Manage Apps > Disconnect From Drive
2. Then reauthorizes that App
3. Files this App was authorized to see with DRIVE_FILE scope are no longer authorized.

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.

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屋！