Google Drive users will know that the oAuth access needs to be reconnected after 7 days. This is not an rclone bug, but a google Drive feature.
I have several google-drives connected to a union, and do weekly backups on this union.
The reconnect every week to refresh the credentials for acessing the google drives is very annoying and takes a lot of time. Recently google login requires dual factor authentication which adds another time consuming step in the process. It takes half an hour or more for doing that for all accounts.
Is there some way this process can be speed up? Via script to feed username and password and go with the rclone config defaults on the questions?
Please post all details as asked when you opened this thread.
I have Google drive authenticated and running for years I think. So you definitely are doing something wrong. Rclone has no issue with renewing expired tokens automatically.
Most likely you did not follow rclone docs and put your Google client ID in testing which is valid only for one week indeed.
Keeping the application in "Testing" will work as well, but the limitation is that any grants will expire after a week, which can be annoying to refresh constantly. If, for whatever reason, a short grant time is not a problem, then keeping the application in testing mode would also be sufficient.
You decided that it is sufficient for you so live with it:) Please read docs first before complaining.
Thanks Kapitainsky for the comment - despite being so direct that some may find it rude - your comment is helpful and i have setup an account as per your description and shall know within ~10 days whether this method still works to keep the credentials alive beyond the 7 days. Results will be posted here.
Pls. note that Google Drive Management Console has changed their layout / interface and your descriptions are not accurate - I could make my way after a lot of clicking and trying and searching, but guess that new users will be completely lost. If you want to consider updating your description accordingly?
When you offend community intelligence by asking questions which are clearly answered in documentation and other forum posts (yes there is search functionality here) then do not expect warm welcome and praise.
Now as we exchanged our point of views back to business:)
In case of documentation - thank you for noticing areas where it should be improved. It is never ending quest to keep it updated. Now ideally you could submit PR (which would be extremely welcomed). However small improvement it helps - it is open source project at the end.
It is very easy, go to:
click edit (top/right - pen icon) and you can edit, fork and submit PR. Do not worry that something might be wrong - somebody will review it anyway before merging.
Similar to the OP, I've found the weekly reconnects a bit of a hassle. I took a spin thru the doc you shared, and it looks like I just missed the step of "publishing" the app.
However, it appears to be a bit more involved than the docs suggest. The bottom of the section currently reads:
Be aware that, due to the "enhanced security" recently introduced by Google, you are theoretically expected to "submit your app for verification" and then wait a few weeks(!) for their response; in practice, you can go right ahead and use the client ID and client secret with rclone, the only issue will be a very scary confirmation screen shown when you connect via your browser for rclone to be able to get its token-id (but as this only happens during the remote configuration, it's not such a big deal). Keeping the application in "Testing" will work as well, but the limitation is that any grants will expire after a week, which can be annoying to refresh constantly. If, for whatever reason, a short grant time is not a problem, then keeping the application in testing mode would also be sufficient.
But glazes over the fact that Google requires an application homepage, privacy policy, demo video, etc:
Yes you missed something clearly. Or have not read everything.
DO NOT publish and verify your app - 99.9% of people do not need it really. And do not put it in testing mode as then as per docs:
Keeping the application in "Testing" will work as well, but the limitation is that any grants will expire after a week, which can be annoying to refresh constantly. If, for whatever reason, a short grant time is not a problem, then keeping the application in testing mode would also be sufficient.
People make mistake here thinking that in order not to go through lengthy verification process they have to use testing mode - and then their token expires after one week.
Without all above, also as per docs:
in practice, you can go right ahead and use the client ID and client secret with rclone, the only issue will be a very scary confirmation screen shown when you connect via your browser for rclone to be able to get its token-id
Which is exactly what 99.9% people should do.
As I mentioned already - this is rather clear for me when reading docs what and how to do but I accept that seems that for many people it is not. I do not understand what is not clear here though so I suggest somebody with this problem update docs making it better. rclone is open source project - if you want it better then do a bit of work on it too.
What is also important here is that it has nothing to do with rclone but is Google way of doing things. So any complaints should be addressed to them.
Ah maybe I wasn't clear. I'm the 0.01% of people who don't want to reconnect rclone weekly, so I was seeking to publish the app.
I also thought the docs were very clear that testing mode meant I didn't need to publish, but came with the caveat that the token needed to be refreshed every 7 days. Publishing would remove the 7 day refresh, but requires verification.
What I was seeking clarification on was that Google is asking for a lot of information, some of which is not accessible or free for most users. The rclone docs don't mention this, so I just wanted to double check if there was a step I had missed which didn't require me to provide this information.
Nobody wants to reconnect it weekly and nobody wants to publish and go through all verification neither. And 99% don't.
Only 1% who can not read with understanding do:)
Again:
DO NOT publish and go through verification - it is mission impossible anyway:)
DO NOT put it in testing mode - as it causes token expiration after 1 week,
then when authenticating rclone config in web browser you will see:
this is where paying some attention is needed:) As "Go to appname (unsafe)" - marked with red marker above - is only visible after clicking tiny "Show Advanced" link. On picture above it was already clicked and shows "Hide Advanced".
Nothing expires (my oldest token is active for years now) and everything works. I have done it countless of times.
If official docs are not clear follow my simplified version for dummies:
I use it myself as rclone docs contain too much noise for my liking. And I do not like to think too much when doing it.
Ahhh okay! I've realized the nuance here: Google makes it sound like there's only two states your project can be in - testing or production verified.
However what you've been trying to explain is that we can submit to production, but not do any verification, and the app still works.
I think I was also led very astray by this paragraph in the docs:
Be aware that, due to the "enhanced security" recently introduced by Google, you are theoretically expected to "submit your app for verification" and then wait a few weeks(!) for their response; in practice, you can go right ahead and use the client ID and client secret with rclone, the only issue will be a very scary confirmation screen shown when you connect via your browser for rclone to be able to get its token-id (but as this only happens during the remote configuration, it's not such a big deal). Keeping the application in "Testing" will work as well, but the limitation is that any grants will expire after a week, which can be annoying to refresh constantly. If, for whatever reason, a short grant time is not a problem, then keeping the application in testing mode would also be sufficient.
I interpreted this as: if you submit to production, you have to verify to get out of testing mode. But if you don't want to verify, you can still use it but are stuck with the weekly token refreshes.
Problem is I do not read it like this:) But maybe only because I know what the answer is. And this paragraph needs re-write to be properly idiot proof (which is btw not derogatory term in my lingo but highest level docs can achieve:))
Please consider making changes to rclone docs to improve it.
By no means I would claim that docs are perfect. And when doing something too often one can not see what is wrong. Only other users can easily spot such issues.
Click edit in github and suggest what should be made more clear. Link included in earlier posts in this thread.
