Why not get rid of appspot dependency at all?

[flurischt]

Hi
From what I saw in the discussions in the original repo the plan is to fix appspot and ask Amazon for a new client id. I'm just wondering: Why keep using appspot as a middleware?

Wouldn't something like this work:

• Spin up a simple Python webserver on port xyz (on the client)
• Start the oauth authentication process and use http://localhost:xyz/... as redirect url
• fetch the token, shutdown the webserver and run acd_cli

Personally I'd trust such a solution more than something that passes my token through a non Amazon middleware.

[calisro]

Yep. I was discussing this yesterday with others. Totally agree.

#1 (comment)

[bgemmill]

I'm going to learn about amazon's security profiles today; this approach may not be possible if amazon requires one whitelisted app; that proxy will need to run somewhere and I'd guess why the current system was built the way it was.

[calisro]

Rclone doesn't use a proxy. The proxy is done on the client.

[flurischt]

I don't think an external proxy is needed. The client id (or however Amazon calls it) is just to identify what application is talking to the api and this way the user can see in the settings which applications have access to the drive. If Amazon allows any redirect urls then in my opinion there's no need for an external proxy. Let me know if I can be of any help.

[bgemmill]

Thanks @calisro and @flurischt, I'll see about what can be done locally if a key opens up.

[bgemmill]

Better answer: because the security profile would be publicly visible, and other apps could masquerade as acdcli. Rclone has this issue due to not running a proxy.

I'm not sure if that's a showstopper (especially if rclone does it), but it at least answers the ticket.

[calisro]

Instead of exposing the security profile ID, the thousands of clients instead incur the risk of an intermediate server spilling tokens due to either malicious or accidental reasons? ha. With that intermediate server there is NO WAY TO PREVENT the owner of that server (or anyone who has the means to access it) from viewing everyone's unencrypted files. Worse yet, you wouldn't even know it happened. 👍 oh and this also means you have a single point of failure outside of the actual ACD service.

"Fool me once, shame on you. Fool me twice, shame on me."

[bgemmill]

The ticket is labeled as "why not...", so that was my devil's advocate hat. I'm with you on this one. More generally, since the model here is really users accessing their own files, we're hitting a strange case of oauth tokens since the third party access is the user.

[flurischt]

Maybe one more comment about this: Another upside to moving the webserver to the client is the appspot api limit. The current proxy seems to be hitting the limit a lot. Only solution is to either pay or move away from there. I don't think yadayada would want to pay the resources of this proxy.

[flurischt]

https://www.reddit.com/r/DataHoarder/comments/6c9fnj/acd_support_may_return_to_rclone/

Seems like having the secret local is not an option. Then a proxy is the only way. :(