search

asjoyner / shade

SHA Drive Engine stores files in the cloud, in a flexible fashion, optionally encrypted.
Apache License 2.0
7 stars 3 forks source link

Provide standardized way to handle OAuth redirects in-process during auth #6

Open cfunkhouser opened 7 years ago

cfunkhouser commented 7 years ago

Currently, both Google and Amazon OAuth flows (assuming https://github.com/asjoyner/shade/pull/5 is accepted) involve copying redirect URLs into the console to parse the authorization code. Instead, there should be a standard utility the various Drive implementations can use to handle this automatically by:

1) Listening on a local port 2) Generating an OAuth redirect URL 3) Accepting requests to parse auth codes 4) Returning the auth code to the calling implementation

Optionally, it should allow the user to configure a hostname for the redirect URL, in case Shade is running somewhere other than localhost.

asjoyner commented 7 years ago

From some years of experience and many users tinkering with OAuth in the fuse_gdrive client, I've learned that it's occasionally tedious to setup the right connectivity path so that your browser can reach both the cloud drive provider and your shade binary at http://localhost/ (typically it involves SSH tunnels). Using a URL other than localhost would require that shade be internet accessible (not always true) and that the user setup their own API credentials (as the URL is typically explicitly whitelisted in the cloud drive provider's web API, a good security practice).

I'd suggest that if the "Authorization Code" OAuth flow (I think that's the right way of saying it?) isn't easy (and I think it wasn't possible with Amazon Cloud Drive), then we should homogenize on the workflow the Amazon Cloud Drive client uses: have the user paste the entire localhost redirect URL into the shade command line, and have it parse out the URL parameter it needs.