Drive File Picker still works even without App ID?

[Dave A]

Hi All,

I have a bit os a mystery here and could use some insight. My public Add-on has been using the full /drive scope for years. Per Google's guidance, I'm going to switch it soon to use the /drive.file scope instead. I already use the Drive File Picker, so in theory this shouldn't cause any access issues. Except... several years back when I copied the Drive File Picker sample code from Google, the sample didn't have the .setAppId() call in it. Ergo neither does mine. 

But unexpectedly, everything still seems to work. Like when I change the dev version of my Add-on to use only /drive.file, it is still able to access files previously selected with the picker. And as expected, if I try to access a file that hasn't yet been selected, it can't open it (gets an error) until I select it with the picker, after which my Add-on can open it. 

I suspect that it is working because of this: the token I am passing to the picker (via setOAuthToken() ) is the token from my Add-on itself (obtained from Apps Script's ScriptApp.getOAuthToken() ). Ergo perhaps the picker is extracting certain data from that token (like OAuth client id, or even the app id) and writing it to the file's metadata to ensure future access.

But even though everything seems good, I am still worried that when I switch my production Add-on to use /drive.file, things might break for existing users who have been selecting files for the past few years.

Has anyone seen or had a similar issue, or hav any thoughts about this?

Best,

Dave

[Darren D'Mello]

Hi Dave,

Once you confirm the narrow scopes to the OAuth support team, they would confirm with an email "Remove Border Scopes", which you should be removing from Console project as well as apps script project.

By this time, you wouldn't have any scopes that have getFileById()/drive scope function calls and hence this should not be an issue.

Your new drive.file no longer expects getFileById() calls, hence the adapted code would work for the old issued token too.

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/e4684950-b3eb-449f-8e1b-71bb4b7cbba5n%40googlegroups.com.

--

Best,

Darren

[Dave Abouav]

Hi Darren,

Thanks for your reply.  Regarding your statement:

"Your new drive.file no longer expects getFileById() calls, hence the adapted code would work for the old issued token too."

That is not the case for my Add-on. I store the user's selected file id (from the picker) as a document property. After the scope migration, the Add-on will still read that property and attempt to open the file by its id (via the Advanced Drive service Drive.Files.get call). What I want to know is if I can expect the read/open of the file to succeed, based on the way my picker has been implemented all this time (i.e. not passing App Id).

Dave

[Dave Abouav]

I setup a separate testing rig outside of my Add-on and couldn't reproduce this. That is, I found that I always needed to call .setAppId() for access to work (as expected). I guess something was amiss with my Add-on, perhaps a sticky scope or mistake in my testing. In any event, we can consider this matter closed. 

This should serve as a notice to developers though: make sure you are calling .setAppId() if using the Drive API picker, especially if you plan to migrate from a full /drive scope to the recommended /drive.file scope. Otherwise users of your Add-on won't retain access to files they've previously selected once you make that change.