pimutils / vdirsyncer

📇 Synchronize calendars and contacts.

Home Page:https://vdirsyncer.pimutils.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Cannot Authorize Google in SSH Session

five2seven opened this issue · comments

I've followed the steps from #975 but the issue I'm having is that pasting the code generated from my browser into the SSH window does nothing. It's not accepting input after saying "Follow the instructions on the page."

  • Your vdirsyncer version: 0.19.1
  • If applicable, which server software (and which version) you're using
  • Your Python version: 3.8
  • Your operating system: Ubuntu 20.04
  • Your config file: Basic Google/Nextcloud that's been working for years
  • Use vdirsyncer -vdebug for debug output. The output is sensitive, but
    please attach at least the last few lines before the error (if applicable),
    censored as necessary. This is almost always the most useful information.

This is where I'm stuck:

Opening https://accounts.google.com/o/oauth2/v2/auth?response_type=code&client_id=999999999999-vqa6roj8c0kbnvu4fv0mdu92bt4qjgl5.apps.googleusercontent.com&redirect_uri=http%3A%2F%2F127.0.0.1%3A52447&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcalendar&state=MMtv8oFuXcCmGGc5quGOrPGmbJRsdt&access_type=offline&approval_prompt=force ...
warning: No graphical browser found. Please open the URL manually.
Follow the instructions on the page.

I paste the code where the cursor is in the SSH window and hit enter, nothing happens and prompt doesn't move to next steps.

commented

For context, Google dropped support for the authentication flow that we previously used (which was the one designed for desktop applications), but hasn't provided any suitable replacement.

We're currently using the flow that's designed for web applications, and our design expects you to be running vdirsyncer on your local machine.

As a workaround, you can set it up locally and copy the token file to your remote machine. Regrettably inputting the token via the cli isn't implemented right now (though should honestly be doable).

I have the same setup and can confirm the workaround works fine for me. I simply run vdirsyncer discover google_calendar on my local machine, abort by not creating the local collection, scp the token file to my remote server and use it there running vdirsyncer sync through a cronjob.

Thank you guys for your responses, that definitely points me in the right direction. The only problem though, is that all of my computers are Windows. The only Linux machines I have are VPS. Do you think I could set this up with WSL?

Probably. Otherwise you could just boot Linux from a USB pendrive or run it in a VM for that purpose. An alternative might be to configure your SSH with X-forwarding so you could open the VPS's graphical browser on your local machine. I have no clue how to do that on Windows though and have no interest in offering free (as in free beer) support for a non-free (as in freedom) OS.

For context, Google dropped support for the authentication flow that we previously used (which was the one designed for desktop applications), but hasn't provided any suitable replacement.

We're currently using the flow that's designed for web applications, and our design expects you to be running vdirsyncer on your local machine.

As a workaround, you can set it up locally and copy the token file to your remote machine. Regrettably inputting the token via the cli isn't implemented right now (though should honestly be doable).

I'm to assume this means setting it up on a local *nix box, and then copying whatever file we have set as token_file in the ~/.vdirsyncer/config, and then putting on over on the remote server that we intend to be doing most of the syncing? Because I can't get a token file generated in the first place. With "Web Application", Google tells me that my redirect_uri is forbidden, and it hardly matters - since it's always 127.0.0.1 and some random port, which obviously doesn't load anything in the browser.

Tried copying and pasting the code into the SSH session, but that doesn't work.

My specs:

  • Your vdirsyncer version: 0.19.1

  • If applicable, which server software (and which version) you're using: pipx install vdirsyncer[google]

  • Your Python version: 3.9

  • Your operating system: Alma Linux 8.7

  • Your config file: Baikal to Google config - Baikal part seems to be working fine

  • Use vdirsyncer -vdebug for debug output. The output is sensitive, but please attach at least the last few lines before the error (if applicable), censored as necessary. This is almost always the most useful information.

Because I can't get a token file generated in the first place. With "Web Application", Google tells me that my redirect_uri is forbidden, and it hardly matters - since it's always 127.0.0.1 and some random port, which obviously doesn't load anything in the browser.

@tromlet, have a look at this comment which might fix your problem.

commented

The latest release updated the instructions for getting a google token. Please review them when upgrading.

I've the same problem: I'm running vdirsyncer in docker, so it's impossible for me to obtain the token file. I have to run a VM,
install vdirsyncer, run it with google config to get the token, then copy it somwhere else and put in the directory of my docker container.
It's a bit crazy. I ask you if it's not possible to create a script to simply get the token file (and name it correctly), that's also runnable in windows cli. I used that method before for other components, for example this one: https://github.com/IvanVojtko/googlefit-homeassistant/blob/master/get_credentials.py

Thank you

I just used cURL when using vdirsyncer on a remote server. If you follow these steps you don't need to run it locally:

  1. Run vdirsyncer discover google_calendar,
  2. Keep the command running and open the URL in a browser
  3. Go through the Google Flow and see you are redirect to 127.0.0.1. Copy the url you end up at.
  4. Open another terminal on the server where vdirsyncer is running
  5. Use cURL like this: curl "PASTE_URL_HERE", mind the quotes else the & might be parsed wrongly by your shell.
  6. The discover should now continue

Note: This also works for the Docker Container, if you execute the cURL in the container.