gmi auth on headless remote server

[stdbull]

gmi auth on headless remote server

[gauteh]

Hi, thanks for your detailed message! The whole thing is pretty confusing. Did you ever try authing locally, and copying the token over? tir. 7. feb. 2023, 14:27 skrev stdbull ***@***.***>:

…

Hi. I’ve used lieer from the early gmailieer days for my personal email, and I migrated one of our work systems to use lieer with GSuite (now Google Workspace) in mid 2019. Both have been rock solid. Thanks for developing and supporting a really great tool! The work system I admin that uses lieer is a headless server, accessible only by ssh. I’ve come to re-auth using gmi and have run into a problem which appears to be related to recent Google changes, i.e. https://developers.google.com/identity/protocols/oauth2/resources/oob-migration This change has been reported and discussed in detail on here already. I could not get the re-auth to work successfully with the current tip of master, until today where I experimented with some ssh port forwarding. I don’t quite understand the change that was made in a4ab209 <a4ab209> which is the solution to this problem. I'm hoping somebody can clarify it for me. Prior to this commit, gmi already supported the --noauth_local_webserver argument which I've used successfully many times on the server in the past. I understand that Google have change the landscape somewhat meaning that this will now not work. From what I can tell, since a4ab209 <a4ab209> we now have two different ways of doing auth via the command line: gmi --noauth_local_webserver auth gmi auth --noauth_local_webserver Is there a difference between these? If so, what is it exactly? gmi --help says: --noauth_local_webserver Do not run a local webserver. gmi auth --help says: --noauth_local_webserver Do not run a local webserver (no longer supported by Google) These two pieces of help text imply there is a difference. In the second case, is it that *not* running a local web server is not supported by Google? Or is is that running a local web server is not supported by Google? See why the double negative is confusing? :-) Up until today, I was not able to re-auth my server. I tried various incantations of 'gmi --noauth_local_webserver auth ' and 'gmi auth --noauth_local_webserver ' like trying to specify host and port. Nothing worked. Then I port forwarded localhost:8080 on the server to localhost:port my own dev machine over ssh, and I *was* able to auth by doing ''gmi --noauth_local_webserver auth' and using the URL provided by lieer as part of the auth process. Do the recent Google changes mean that if using lieer on a remote machine where one cannot start up a browser, unless similar SSH port forwarding is done auth/reauth is (now) not possible? This is what worked for me, fyi ssh -f -N -L localhost:8080:localhost:8080 ***@***.*** SSH into the server and run gmi --noauth_local_webserver auth Then paste the link generated into my browser. AFAICT *not* specifying --noauth_local_webserver tries to fire up a browser, but this won't work on a remote machine unless there is a tunnel for X / UI, e.t.c.. In my case, this problem is compounded by there is no 'modern' browser installed on the server anyway :-) So can --noauth_local_webserver prior to commit a4ab209 <a4ab209> still work *if* one can access localhost:8080 from the machine running lieer? I thought this was broken by the recent Google changes? Confused...! Any offerings of clarity greatly appreciated! Cheers — Reply to this email directly, view it on GitHub <#235>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAN367JS4DW4KWGT2UDZUTWWJET5ANCNFSM6AAAAAAUT65P6M> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[stdbull]

I thought about doing that, but only after I had success with SSH :-) At that point, it didn't seem worth it. I wish I'd have thought about it earlier though as it would have saved me several days :-)