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

DRIVE not authenticating from CLI #250

Open
lecrabe opened this issue Nov 22, 2022 · 7 comments
Open

DRIVE not authenticating from CLI #250

lecrabe opened this issue Nov 22, 2022 · 7 comments

Comments

@lecrabe
Copy link
Contributor

lecrabe commented Nov 22, 2022

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
Copy link
Member

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

@cdanielw
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

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
Copy link

bsidhom commented Dec 26, 2022

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
Copy link

bsidhom commented Dec 26, 2022

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

@jelabarre59
Copy link

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.

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

5 participants