what does that mean???
I have no idea what that project as I've never used it before.
If you can't get API access on the app from your admin team, you can't 'trick' it to work in anyway unfortunately.
For anything on the API, you'd have to contact your admins if you want to get API access as there's not much we can do to help.
I'm not making myself clear.
I'm not trying to 'trick' the app to work without API access. I know that that's futile.
What I'm asking is: how is it that other apps are able to overcome the 'sensitive scopes' restrictions that have blocked rclone? For example (to answer your question, asdffdsa), the linux command-line app gdrive, which I just successfully installed and have now tested on my linux server, has no more nor less access to my Google Drive than rclone ever did--it can see everything, copy anything--yet the whole procedure that's basically identical to rclone's "config reconnect" (i.e., copying the URL from stdout to a browser and then copying back the reply on the command line) works fine with gdrive: you get a dialog box from Google saying what you're giving the app access to and it all works.
What I'm getting at is: I don't think the admins at my workplace specifically banned rclone from API access. The language I got when I tried the config reconnect procedure suggested it was a 'policy' ban, implying it isn't just the say-so of an administrator.I think they banned any non-verified app from access. So: how is it that gdrive can be verified such that it can have access to 'sensitive scopes' but rclone, apparently, cannot?
Is that clearer?
now that you have tested the gdrive app, i think that is a good question.
the gdrive app works, rclone app does not....
Did you ask your admins? They can white list apps and do whatever they want. It's up to them on how they configure it.
I use an unverified app as an app does not need to be verified to be used.
I didn't ask the admins because that would open a can of worms. I work in an organisation with thousands of employees and thousands more authorised users. I'm not even sure I'd be able to find the right person to ask.
What I don't understand here is this:
gdrive and the other half-dozen or so apps that still have access to my Google Drive all treat authentication in the following way:
The app is "verified" with Google for access to the Drive by its developer. When the end user wants to hook the developer's app into Google Drive, they are presented with a screen that explains to them what the app will have access to and be able to do. They then either give it permission or not.
With rclone (uniquely among the apps I have/had connected to GD on two platforms) the situation is totally different. In order to access Google Drive, you have to set up a Client ID and, for some reason, this puts you not in the position of an end user but that of a developer. Now, under the new "enhanced security," you--the end user--are expected to submit your "app" (what app??) for "verification." Yes, @ncw has put in place a workaround but for some (and perhaps increasing numbers) it won't work: GD now expects you to go through the "verification" process of the end user's "app" that wants access to the API of a drive with "sensitive scopes." And verification involves: pointing to the "app developer" (in this case, the end user's) web domain and the "app developer's" (i.e. end user's) "privacy policy" and a whole lot of other stuff that no end user of rclone is likely to have for this purpose.
The question is: why, uniquely, does rclone behave in this way? Why doesn't it follow the model all the other apps I know of follow--including gdrive on my linux server--in which the app developer is responsible for getting the app "verified" and then, when the end user wants to connect the app to Google Drive, he/she gives the app permission? And is it not a big disadvantage for an app like rclone, uniquely, to put its users into the position of "developers" just for the purpose of having a client ID?
There may well be very good reasons for this and I'm the first to admit that I have less technical knowledge of any of this than most of the contributors here. I'm just trying to understand why gdrive was able to get access despite "sensitive scopes" when rclone cannot and requires me to verify my "app" as if I developed it.
Perhaps @ncw could explain?
The app acces is determined by the admin(s) of your organization.
Some organizations block nothing, some block access from rclone, some block both rclone and gdrive from non-organizational devices. There are many possible combinations. It really depends on their need to ensure security and proper usage - and it doesnāt always make sense in all situations.
If your usage is proper and needed by your organization, then I suggest you contact your admin - otherwise I suggest you hold a low profile and stop complaining here.
Iām sorry if it came across as complaining. Iāve expressed in the past to @ncw how grateful I am for rclone. If it turns out that I can no longer use it as I did, then so be it: Iāll move on after a good run.
However, your response doesnāt really answer my question. Why does rcloneās authentication implementation require the end user to effectively be a developer as far as Google is concerned?
I ask because, while it may be true that the admins at my organization specifically blocked rclone and left gdrive in place (even though the security risks are similar), it may also be true that they simply blocked any āunverifiedā app. So itās an open question and not an open and shut one (yet).
Your response isnāt exactly what I consider low profile without complaining.
If you have tried rclone without using your own client ID and get the same error, then I am pretty sure you have exhausted your possibilities to use rclone.
I think we've answered this one a few times.
The admin of your org can answer that question as they choose to block or not block any app they want. If you want to know what they blocked, you have to ask them.
You don't have to be a developer to use rclone. You need access to the Drive API. That's it.
Step 9 of the āSetting up a client IDā instructions says:
āGo to "Oauth consent screen" and press "Publish App"ā
Why, exactly, do I have to āpublishā an āappā in order to be able to authenticate myself to Google Drive?
You don't. My app is not published.
There are numerous discussions on updating the instructions to be a bit more clear as the options have changed over the years.
I linked a few posts up to the API area explaining why it needs or does not need to be published.
You don't need your own client ID/secret to use rclone. That's only for using your own API quota rather than using rclone's shared client ID/secret.
Regardless if you are use your own client ID or rclone, you need to authenticate your app to connect. If your admin blocks the API request from rclone, you can't get around it.
Only asking the admin would know what he/she/they have configured.
We keep circling on the same thing. You'd have to ask your admin what they have configured if you want to use rclone.
1 Like
I've now connected successfully without my client ID. I hadn't even thought about trying that. Obviously my employer did not block rclone. So what's the conclusion about what happened with my client ID?
It got revoked.
Thatās helpful.
Thanks, you are welcome 
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.