Next Totally Unscripted Episode on verification and editor add-on publication 05 June 2019 1900UTC

[Martin Hawksey]

Hi all,

Delighted to announce that in the next episode of Totally Unscripted we'll be joined by Eric Koleda to talk Google Apps Script verification and Editor Add-on Publication. 

You can join us Wed. 05 June 2019 at 1900UTC by visiting https://youtu.be/C5_lw6OFiC0 or adding the calendar event at https://tu.appsscript.info/

YouTube chat will be open and we'll post a Q&A link during the show.

Hope to see you there!

Thanks

Martin

[Faustino Rodriguez]

Thanks @Martin a lot for arranging this event with @Eric

- Great timing for such an important topic

I thought that it might be useful to have some questions ready ahead of this event, in case Eric has the chance to look at them in advance

1. When using oauth/drive.file scope, "View and manage Google Drive files and folders that you have opened or created with this app" (the bold is mine)

- In my experience, a file created by the app by user A, then shared with user B (view access), cannot be opened by user B using the same app. Is that the intended behavior?

- Would it be enough for user B to add that file to a folder, also created by this app by user B, to being able to access that file?

- Or would it be also required that user B opens that folder, with the Google Drive Picker, to being able to access that file?

- Or the Drive Picker actually has to 'open' that file?

- Or something else is also required?

2. When downgrading a script add-on scope, from oauth/drive to oauth/drive.file

- Each user that previously installed the add-on and authorized the oauth/drive scope, has to reauthorized the add-on to all the scopes including oauth/drive.file

- BUT, during this process Google is not removing the previous, no longer present, oauth/drive scope. I believe this is a critical issue in this process, but also

- From that point on, the Google account Security Checkup is flagging the add-on with risky access and the app as from an "unverified developer"

- Also, in some cases, Google is sending "Security advice" email notifications about the add-on and recommending to "Remove risky access to your data", with some more scary content in the message

- Is there any chance of Google fixing this problem?

- Or should we go with plan B as suggested by @Eric, by revoking the token if oauth/drive scope is included?

3. For open source apps, like Gnome @ Ubuntu Online accounts option, that uses both Gmail and Drive restrictive scopes (and more)

- Would they keep working?

- I don't imagine an open source project doing the security assessment ...

Thanks, Fausto

[Dimu Designs]

Definitely looking forward to this one. 

On Friday, May 31, 2019 at 6:38:28 AM UTC-4, Martin Hawksey wrote:

[Davis Jones]

Nice! I'm going to try to attend, 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.
Visit this group at https://groups.google.com/group/google-apps-script-community.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/ba5314ef-ef06-444b-848d-96bbae46e3cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Hawksey]

Hi Fausto,

Thanks for these. I think there is a lot to discuss around drive.file scopes and also noted a thread on the File Picker and practicalities around files that might have been added via other means such as Google Forms file upload.

I also encountered an issue today where I had limited oauth to internal in the console project but was not able to access a branded youtube account associated to our domain ... this one is perhaps more niche.

Happy to have more questions added to this thread.

Thanks

Martin