Remote server option --noauth_local_webserver missing

[pwoefhidkln]

I'm running version v4.0.4 quite happily using --noauth_local_webserver

I've just installed v4.4.0 but the option has disappeared and I can no longer authenticate.

Has it been dropped or just missed out?

[dbarnett]

Hmm, it was removed intentionally as part of #683, unsure whether there's still a way to support it in the new google_auth_oauthlib mechanism but either way I'm hoping to get a 4.5 release out in the coming weeks and can see if a fix for local webserver is feasible as part of that.

I'm a little surprised it's been working for you recently on the old version, thought I saw something about that mechanism going away completely… Can I check in with you here next week for a few more details about your use case and how it's worked in the past?

And I assume in the meantime you have a way to downgrade and keep using the old version that you said is still working for your case?

[pwoefhidkln]

I didn't get to the bottom of the OOB flow issue, but two points: a) It works. I have a Pi which uses gcalcli to dump my calendar. I ssh to the Pi from my laptop, authenticate using --noauth_local_webserver and c&p the code given from the oauth page to the ssh client b) Google loves that OOB error. When I mistyped my email address in the authorised test account box I got that error. When I ouath using the wrong Google account I get it. Also when my creds expire and also when I try to reauth without deleting the cache files first. Happy to help, I'm using the Pi's distro's version of gcalcli and would like to upgrade. No problem downgrading, the Pi's running away happily in the background. I tested the pip installed one on a VM. Thanks!

…

On Fri, 6 Sept 2024 at 23:02, David Barnett ***@***.***> wrote: Hmm, it was removed intentionally as part of #683 <#683>, unsure whether there's still a way to support it in the new google_auth_oauthlib mechanism but either way I'm hoping to get a 4.5 release out in the coming weeks and can see if a fix for local webserver is feasible as part of that. I'm a little surprised it's been working for you recently on the old version, thought I saw something about that mechanism going away completely… Can I check in with you here next week for a few more details about your use case and how it's worked in the past? And I assume in the meantime you have a way to downgrade and keep using the old version that you said is still working for your case? — Reply to this email directly, view it on GitHub <#734 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BLCQKA54QAZKYVDSGOYU4G3ZVIQ6HAVCNFSM6AAAAABNY4WI5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZUHA3DMOBZGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[dbarnett]

K I had a look through details and options here...

First the bad news: AFAICT, like dgrieser said in the PR, it's literally impossible to support the same exact usage model of a --noauth_local_webserver arg. The old option seemed to depend on remote Google servers to relay the connection and would be brittle-to-impossible to try to hack into the google_auth_oauthlib client.

The good news: it's not that hard to get the same effect with SSH port forwarding (like ssh -L 8080:localhost:8080 <host>), AND we might be able to add some convenience helpers to make it a smoother transition for folks used to using that option.

The one complication is deciding which direction to tunnel: in the case of your Pi you'd want to tunnel IN from another system, whereas in other cases it might be more convenient to tunnel OUT to a remote host, and maybe even automatically launch a browser pointed at the auth URL.

Either way, I think it'd be worth making it accept the --noauth_local_webserver arg and spit out suggestions for how to connect to it remotely. LMK if you have any suggestions for preferred instructions or helpers you'd want to see in your case.

[dbarnett]

K, dunno if it'll scratch your exact itch but I got some quality-of-life improvements for those cases that'll be incorporated into the upcoming 4.5 release. Still gotta copy-paste commands, but should give you a great head start spitting out some example commands with port numbers and such values filled in.

I guess my suggested ssh commands aren't too portable to Windows etc probably, but it's way better than just blowing up with a "no such arg" error.

[pwoefhidkln]

That's great, thanks!

[dbarnett]

On second thought, there may be some gotcha I'm missing but it seems like it still could work without a tunnel if the devices are on the same network and the remote host can reach the system running gcalcli, where currently we hard-code the target to localhost.

Might revisit that design later if it the SSH tunnel process is still particularly annoying for folks.