search

openforis / sepal

Geographical Data Processing in the Cloud
https://sepal.io/
MIT License
203 stars 45 forks source link

DRIVE not authenticating from CLI #250

Open lecrabe opened 1 year ago

lecrabe commented 1 year ago

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 image

12rambau commented 1 year ago

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

cdanielw commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Here's the issue: https://github.com/odeke-em/drive/issues/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: https://github.com/odeke-em/drive/pull/1142

bsidhom commented 1 year ago

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 commented 1 year ago

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

jelabarre59 commented 1 year ago

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.