gauteh / lieer

Fast email-fetching and sending and two-way tag synchronization between notmuch and GMail
http://lieer.gaute.vetsj.com
Other
494 stars 60 forks source link

gmi auth on headless remote server #235

Closed learmj closed 8 months ago

learmj commented 1 year ago

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 a4ab209c721de7146f4301b426bdb6482d687a85 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 a4ab209c721de7146f4301b426bdb6482d687a85 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 user@remoteserver 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 a4ab209c721de7146f4301b426bdb6482d687a85 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

gauteh commented 1 year ago

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 https://github.com/gauteh/lieer/commit/a4ab209c721de7146f4301b426bdb6482d687a85 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 https://github.com/gauteh/lieer/commit/a4ab209c721de7146f4301b426bdb6482d687a85 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 https://github.com/gauteh/lieer/commit/a4ab209c721de7146f4301b426bdb6482d687a85 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 https://github.com/gauteh/lieer/issues/235, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN367JS4DW4KWGT2UDZUTWWJET5ANCNFSM6AAAAAAUT65P6M . You are receiving this because you are subscribed to this thread.Message ID: @.***>

learmj commented 1 year ago

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 :-)

gauteh commented 8 months ago

I'm guessing this is no longer relevant since we have a new oauth flow.