DRIVE not authenticating from CLI

[lecrabe]

Describe the bug
When using drive init as described here https://docs.sepal.io/en/latest/cli/gdrive.html, we get an Error message

To Reproduce
Steps to reproduce the behavior:

1. Go to TERMINAL
2. Type drive init
3. Copy Paste the AUTH link

Expected behavior
Get the following error message: Access blocked: drive for Google Drive’s request is invalid

Screenshots

[12rambau]

I think it's related to #196 as we get the same error message

[cdanielw]

We're using this: https://github.com/odeke-em/drive. It was an old version, but even the latest release (still two years old though) fails. There obviously have been some changes on Google's related to authentication, breaking this version of the drive cli. It might be related to the old EE API failing too.

For now, I will focus on EE - I'll get back to this afterwards. You could perhaps have a look at other Google Drive CLI projects, and see if you can get something to work?

[12rambau]

on my local machine I was force to use the gcloud sdk to make it work. Which is very unoying as you need to decide a cloud project to authenticate

[cdanielw]

Here's the issue: odeke-em/drive#1140

Someone created a patch, but we have to verify if it works. It seems to be using some kind of proxy server, which probably won't work in SEPAL: odeke-em/drive#1142

[bsidhom]

I'm the author of that patch. There's no proxying involved out of the box. It just creates a server on the local loopback device and has the web browser forward auth tokens to that.

However, I did test the patch with remote port forwarding to ensure that it worked when used over a SOCKS proxy. In my test, I had SSH access to the remote server (which actually ran the drive command). Then, I ssh'd into that server while using a SOCKS proxy (you can use ssh -D <port> to do so with OpenSSH). Finally, when it came time to open the auth URL, I opened it in a chrome session what was configured to use the SOCKS proxy I set up earlier.

I'm not sure exactly what SEPAL is or how it's deployed, but this could potentially work as long as users have SSH access to the machines where it runs. Unfortunately, it's a pretty involved process, and it also looks like each client may need to use its own OAuth client ID now (I think the default client ID is being blocked by Google since it was not updated to use the loopback flow, which is the only auth mechanism supported for desktop apps).

[bsidhom]

I also mentioned this in a Drive thread, but Rclone is an alternative that may work for you.

[jelabarre59]

Rclone is no good for my needs. THIS is the only sync utility that can export GoogleDocs to ODF and PDF files. Everything else will just create symlinks to the online document editor. I want LOCAL backups that I can use locally, without having to depend on Google.

If I can't get that, I'm going to have to find a different place to keep/work on my fiction. And GDocs was handy since I could have keep offline copies of in the Android client (and those "offline" copies are buried somewhere in the morass that is the Android filesystem, most likely in an encrypted proprietary format).

I guess this just Google being dickwads, as is always the case.