Authenticating on a headless system

[PMDant]

I thought it was addressed on 4.4 and on but couldn't find any notes on it. I have a headless system (rpi) that I run this on for my scrolling Marquee and had not managed to need to authenticate since I upgraded from 4.3 to 4.5, until this evening. If a note about this could be added to the documentation that would be awesome. The --noauth_local_(web)server flag was not working... may have had it in the wrong spot... so I just followed the prompts as one would from normal authentication up until the opening a web browser part. Once it paused I opened the link it gave me, followed the prompts then it tried to open the http://localhost:port/auth/code link. Naturally that didn't work and attempting to redirect to the remote IP, my case was internal, didn't either. I copied the link that was given in the local browser, ssh'd a second session into the remote machine, and curl "http://localhost:port/auth/code". After making sure I used the quotes it authenticated as expected.

[dbarnett]

Hmm, did you try the --noauth_local_server option on 4.5? That should walk you through headless setup. I guess I could add a placeholder --noauth_local_webserver back as well that does the same... the options went away when upgrading off of oauth2client that Google deprecated and it wasn't transparent exactly which options disappeared that people would miss.

Besides port forwarding, you're not going to be able to monkey with the URLs to get something to work. Your browser needs to be able to hit the target URL directly to transfer the token.

Dupe of fixed #734, I believe, apart from any additional documentation you might be asking for.

[dbarnett]

I guess as far as docs go, one piece that probably needs an overhaul is the stuff in the README about env vars like http_proxy: https://github.com/insanum/gcalcli?tab=readme-ov-file#http-proxy-support.

Pretty sure those haven't worked in ages but I still never figured out exactly what they were referring to so I wasn't sure exactly what updates to make there. They just appeared in 770393f. @insanum do you have any pointer on those?

[PMDant]

Yeah not sure why the --noauth_local_server didn't work, I used to have a script run it then just go get a new token/code from a saved link but it seemed to not want to play nice. I wonder if it has something to do with the way I am installed. Probably should have removed the old .deb installed version then installed fresh from GitHub. I may try that, and if I can figure it out, I may try to get some updates to the docs in a PR, time permitting.

[dbarnett]

Yeah not sure why the --noauth_local_server didn't work, I used to have a script run it …

To be clear, it's not going to just work exactly like it used to, the behavior has changed. If you're running it deep inside a script then you might just not have noticed the new output, but the gist is that Google deprecated the old behavior and the command now prints some detailed instructions for SSH port forwarding, which is the best available approach right now.

[PMDant]

Ah ok that makes sense, totally glossed over that output until now. Since I do not have a browser installed on the pi I would venture to add a new Option 1 (preferred?): Open https://the-url-below in your local browser and follow prompts until it opens http://localhost:$port/?... (this will fail). Copy the URL from your browser into a second ssh session and 'curl "http://localhost:$port/?..."' This just takes any port forwarding out of the equation. Been a long time since I messed with the forwarding like I used to so just found this easier since any other forwarding attempts were futile.

[dbarnett]

I'm open to ideas for better workarounds but as far as I know if you're not port forwarding you're doing something even more brittle and complicated. The web browser needs to be able to open a connection to the target device and port where gcalcli is running. If they're on the same network and can access each others' IPs and ports are open then you could replace localhost with another address without needing forwarding, but that's almost never going to "just work".

IIUC the reason it was able to work more seamlessly before is that you had remote Google servers helping bridge communication between the two independent devices (the "Out-Of-Band flow" and similar), but Google decided they don't want to support that anymore for some security risk reasons.

[PMDant]

Yeah, that was one of the first things I tried, using the IP and the Domain Name, but I am guessing my pi probably had the port blocked off in the firewall rules because it still failed. That is where I figured the curl command might work since it's just an API call, I use curl to make adjustments to my sound systems linked between my office and garage. curl stands in for the web browser since the data being passed back to the gcalcli is just contained in the URL. Everything after that "?" is just JSON structured API data right?

URL provided by gcalcli init:
https:// accounts.google.com/o/oauth2/auth?response_type=code&client_id=########################################&redirect_uri=http%3A%2F%2Flocalhost%3A_port#_%2F&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcalendar&state=###########################&access_type=offline

redirect_uri from google with code:
http:// localhost:port#/?state=#######################&code=#################################################################################&scope=https://www.googleapis.com/auth/calendar
... this doesn't return anything graphically does it, since its just the python script waiting for some JSON data to be passed? I mean curl didn't show anything I just got the "Successfully loaded credentials" on the first ssh session.

Sorry if this is getting long winded but just had a whole other brain shift... Since the init provided URL doesn't have to run on the headless machine and redirect_uri is where Google redirects back the code to the gcalcli webserver, versus the old out of bounds configuration, can the --noauth_local_server option wait for a paste of that URL that is returned from google and handle the curl, parse the pasted URL for the code, or have the end user just copy the code form the URL?

By the way still, thank you again for all the work you have done on this @dbarnett