Google Drive error: "This app is blocked"

[rosano]

Claims the app tried to access sensitive info.

[raucao]

Looks like they finally clamped down on access to all files and folders, which we needed for different RS apps being able to access the same RS files. Nothing has changed on the Webmarks side. :/

I wonder if we could change it to be an "app folder" level token, but somehow choose the app folder in a way that it is the same as the one used by rs.js at the moment (i.e. /remotestorage/bookmarks in this case).

[rosano]

I wish there was a way to pick which folder to give access, or request multiple scopes, so that the user can point the app where they like.

[raucao]

I just tried it and actually get a different screen for the OAuth dialog, which is a warning about the app not being verified. Then I can trust the app anyway, click continue to the app, and retrieve my data in Webmarks.

Where exactly did you get this screen (i.e. what was the flow that led up to it)?

[rosano]

I just tried it and actually get a different screen for the OAuth dialog, which is a warning about the app not being verified. Then I can trust the app anyway, click continue to the app, and retrieve my data in Webmarks.

In another project I get this kind of thing when authorizing the API with the my own token + my own account (same Google account that produced the token). Do you get the same with someone else's account?

Where exactly did you get this screen (i.e. what was the flow that led up to it)?

After selecting an option from the Google account selector:

[raucao]

OK, thanks. I'm deploying another instance on a different domain and will see if I can migrate the permission. It mostly depends on being able to list files in the same folder (with the drive.file scope) I think.

I needed another deployment to test my new features for folders and readlater in production anyway...

[raucao]

This will be rather messy. Changing the scope to drive.file means apps can only read and write their own files, i.e. whatever was created by the app's Google client ID. I created a new Webmarks client to test that scope, and it created its own root-level remotestorage folder with the exact same name as the existing folder:

Now, let's assume the best case of it still using the existing folder when changing the scope for the existing Google client ID. Then I still have two folders within remotestorage in my case, because Webmarks wrote the bookmarks, but Litewrite wrote documents. So what will happen then? 🤔

[rosano]

Yes I noticed there were two remoteStorage folders, two documents folders and thought it was bizarre; quite hostile to interoperability this way. One solution could be to let people bring/set their own API keys via the connect widget, which might be useful anyway for apps that don't provide Dropbox/Google options but want to let other people use them.

[raucao]

You cannot create OAuth apps without a verified domain anymore, and the whole process is pretty complex for anyone who's not a Web developer. So that's only a solution for a very small number of users, who are able to run apps either locally or on their own server with their own domain, with all the correct settings for their OAuth app registration.

I think a good idea if changing scopes this way is to change the base folder name to the app's client ID, i.e. webmarks.5apps.com in this case. So it's clear which app the data belongs to and which app is able to load and edit it.

There might also be a way to access existing data in the remotestorage folder by using the Google Picker API and letting the user select the existing folder.

[rosano]

change the base folder name to the app's client ID, i.e. webmarks.5apps.com in this case. So it's clear which app the data belongs to and which app is able to load and edit it.

I guess this means decoupling 'storage path' from data and maybe having a preset list of guesses where apps can check, and/or just letting people use a picker (good to know there is one for Google). Maybe it's worth considering the filesystem as a primitive or lowest common denominator amongst various storage options, rather than adapt a potentially hostile system to the remoteStorage protocol.

[rosano]

filesystem as a primitive or lowest common denominator

And another reason would be that perhaps it's useful to let apps access files outside of the remotestorage folder, especially here where there are absurdly multiple instances of the same folder 🤦🏽‍♂️