CLI OAuth workflow never finishes with custom URI in redirect_url

[soumith]

Describe the bug

In the duck CLI, take a simple workflow such as duck -l googledrive:/.
The CLI opens a browser, which does the OAuth workflow.
Once authenticated, the expectation is that you either have the OAuth redirect the CLI or some code shows on browser that you can paste back into CLI.
However, the OAuth redirect_url is set to open the CyberDuck app, and does not respect that the duck CLI originated the OAuth workflow.

To Reproduce
Steps to reproduce the behavior:

1. Go to command-line
2. Run duck -l googledrive:/
3. Try to finish authentication workflow

Expected behavior
You expect the workflow to finish.
Either the OAuth takes you back to CLI and CLI finishes auth, or you get instructions on how to manually finish the workflow.

Desktop (please complete the following information):

• macOS 12.4
• [Also checked] Linux Ubuntu 20.04

Logs with --debug :
foo.log

[dkocher]

This was missed in #13366.

[dkocher]

Not sure how we should implement this, as manual copy & paste of authentication code ¹ is deprecated .

Footnotes

1. Important: The manual copy/paste option, also referred to as an out of band (OOB) redirect method, is DEPRECATED and will be removed in October 2022. Review the OOB migration guide for instructions on how to migrate to a secure alternative. https://developers.google.com/identity/protocols/oauth2/native-app#manual-copypaste ↩

[soumith]

from the migration guide, the most matching option seems to be a loopback IP address -- so cyberduck temporarily listens on some localhost+port and that is given as the redirect_uri

https://developers.google.com/identity/protocols/oauth2/native-app#redirect-uri_loopback

[dkocher]

Relates to #13476.

[dkocher]

from the migration guide, the most matching option seems to be a loopback IP address -- so cyberduck temporarily listens on some localhost+port and that is given as the redirect_uri

https://developers.google.com/identity/protocols/oauth2/native-app#redirect-uri_loopback

We don't currently have an implementation using a listener on the loopback address as it is prone to man in the middle attacks. it is still feasible for desktop apps according to the documentation ¹

…but will continue to be supported on desktop apps.

Footnotes

1. https://developers.google.com/identity/protocols/oauth2/resources/loopback-migration ↩

[dkocher]

You should be able to work with Cyberduck CLI by connecting first with Cyberduck and then use duck --username <email> -l googledrive:/.

[Ripper346]

Can it be done from another machine with cyberduck gui? If we installed duck in a unix system we can go for a walk with that workaround, it is useless in that case

[pedrohgmacedo]

The problem occurs with onedrive as well.

[stuckj]

Also occurs with Dropbox (as mentioned in #14282). Seems like you can't really use the CLI on Linux for any service with an oauth flow since there is no GUI for Linux.

[dkocher]

Find attached ¹ a connection profile for Dropbox that can be used with Cyberduck CLI using

duck --profile ~/Downloads/Dropbox\ \(CLI\).cyberduckprofile --list dropbox:/

• Connection profile for Dropbox using website as redirect URI for inte… profiles#69

Footnotes

1. Dropbox (CLI).cyberduckprofile.zip ↩

[stuckj]

@dkocher, I appreciate your message, but I'm not sure how that is helpful. The oauth client secret is blank in there (and kinda has to be since any secret you gave me would be to your account! :) ). And, you can't complete the oauth flow to get the secret.

I guess if you use a GUI on a windows machine with cyberduck (non-CLI) installed and connect on there you can find the profile on the machine and copy the key from there. At that point, you can just take that whole profile though, right? Where could we find that on a windows machine? Maybe I can just grab it from my windows installation (I dual boot with Linux and Windows).

[dkocher]

@dkocher, I appreciate your message, but I'm not sure how that is helpful. The oauth client secret is blank in there…

The OAuth Authorization Code Flow implemented by Dropbox does not require a client secret and is therefore intentionally left blank in the profile.

[dkocher]

Find attached ¹ a connection profile for Microsoft OneDrive that can be used with Cyberduck CLI using

duck --profile ~/Downloads/OneDrive\ \(CLI\).cyberduckprofile --list "onedrive:/My Files/"

• Connection profile to use with Cyberduck CLI for OneDrive & SharePoint profiles#77

Footnotes

1. OneDrive (CLI).cyberduckprofile.zip ↩

[dkocher]

Make sure to use the --username parameter like

--username dkocher\@iterate.ch

to read saved tokens from the keychain or credentials manager.

[dkocher]

Find attached ¹ a connection profile for Microsoft SharePoint that can be used with Cyberduck CLI using

duck --profile ~/Downloads/Microsoft\ SharePoint\ \(CLI\).cyberduckprofile --list "sharepoint:/"

• Connection profile to use with Cyberduck CLI for OneDrive & SharePoint profiles#77

Footnotes

1. Microsoft SharePoint (CLI).cyberduckprofile.zip ↩

[mcx808]

Find attached 1 a connection profile for Microsoft SharePoint that can be used with Cyberduck CLI using

duck --profile ~/Downloads/Microsoft\ SharePoint\ \(CLI\).cyberduckprofile --list "sharepoint:/"

• Connection profile to use with Cyberduck CLI for OneDrive & SharePoint profiles#77

Footnotes

1. Microsoft SharePoint (CLI).cyberduckprofile.zip ↩

@dkocher Is this an updated profile from the one posted previously?