Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default scope overriding #70

Open
adousa opened this issue Jun 6, 2024 · 3 comments
Open

Default scope overriding #70

adousa opened this issue Jun 6, 2024 · 3 comments

Comments

@adousa
Copy link

adousa commented Jun 6, 2024

Feature Request: Ability to Override Default Google Picker Scope

Description:

I would like to request a new feature that allows developers to override the default scope used to connect to Google Picker. Currently, the library uses a predefined scope

https://www.googleapis.com/auth/drive.readonly

which gives access to see and download all Google Drive files for a user

Use Case:

In many applications, accessing files selected by user in the picker is only required by using:

https://www.googleapis.com/auth/drive.file

@sterliakov
Copy link

You can extend the default scope, but unfortunately not override, so drive.file is just lost (as it's weaker than drive.readonly). I think this can be either changed extremely (never concatenate, use the scopes provided in config if any) with a major version bump or less destructively (add a second option - includeDefaultScope = true). I am ready to contribute either, @Jose-cd may I ask for your opinion on this?

@sterliakov
Copy link

To clarify, this difference is critical because drive.file is a "free" scope that does not require app validation from Google, while drive.readonly is sensitive and requires such audit. This is a deal-breaker for anybody with a burning deadline.

@johnsonfamily1234
Copy link

Is there any movement on this? I'm hitting the drive.file limitation - even when passing an appId it doesn't seem to be working properly. We don't have drive.readonly in our project (google verification process strongly discouraged it) and this is currently a pretty heavy issue for us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants