Finishing touches on Companion dynamic Oauth

[goto-bus-stop]

This PR will contain the final bits we need to start using Companion's dynamic oauth feature on transloadit.com. May add a few more things here as I work on the transloadit.com side…

So far this:

• fails loudly if requested third-party credentials do not exist, instead of silently falling back to the preconfigured one. There was no way for developers to see what went wrong before
• adds options to Robodog so you don't have to remember how companionKeysParams works and don't have to duplicate your transloadit API key. Now you can do:

  robodog.dashboard({
    params: {
      auth: { key: 'your transloadit api key' }
    },
    providers: ['instagram'],
    instagram: {
      credentialsName: 'your instagram credentials name on transloadit.com'
    }
  })

To do:

• when requested third-party credentials can't be found, error out with an HTML page that can communicate back to the Uppy client, instead of a JSON error. – leaving this for a followup PR
• docs for the new robodog options
• Seems to lose preauth state when the initial authentication attempt fails; then falls back to default credentials, which is bad

[goto-bus-stop]

Doesn't work correctly yet even with the API2-side changes, so need to investigate a bit more where it could be going wrong 🤔

[mifi]

Seems to lose preauth state when the initial authentication attempt fails; then falls back to default credentials, which is bad

what does this mean?

[goto-bus-stop]

what does this mean?

IIRC, preauth state refers to the stuff that we need to initiate the authentication. Before starting we fetch encrypted oauth keys from Companion that will be used for the signin. (Those keys eventually come from the credentials storage in one's transloadit account.) Then we send that back to companion when we actually sign in. Companion redirects to the relevant provider login page matching the oauth keys. So the provider will show the user signing in to the correct app.

Apparently if the signin did not succeed, the client forgot about the preauth state (encrypted keys), and trying again would use companion's default oauth keys, which in our case means that users see a "sign in to transloadit" screen instead of "sign in to <website i'm actually on>".

[goto-bus-stop]

I actually cannot reproduce the issue I was running into earlier. I tried failing the login in many ways and it always sent me to the correct app again afterward.

I would like to be 100% sure that we don't accidentally use our default app when end users try to log in to one of our customers' apps. Maybe Companion should never fall back, and instead ONLY load keys dynamically if a key endpoint is provided. On our end we can return default keys from the endpoint if the request body is empty. Or the client could send some parameter to Companion to prevent falling back to defaults if a companionKeysParams value is configured. I'll experiment with both 😇

[mojowill]

As a customer waiting for this, would it not make more sense to simply error out if trying to use a third party like Google Drive etc if the keys have not been set in on the companion? Does there need to be a fallback?

We're using Transloadit as our companion and never want Transloadit to appear in the grant screen of a third party app. If keys aren't configured a developer is usually going to spot that before anything gets shipped to production.

[goto-bus-stop]

That's a good point actually! We have the fallback for developers who are just trying it out and because we use the same Companion instances for our public demos (where you can also import files from third-party services). But we could address the demos in a different way easily, and the fallback for new users is not that valuable. The only risk is that someone may be using the fallback somewhere today (I think most people would consider this PR a blocker, but some small-scale apps may not.) I'll ask if we have any insight into that, because your proposal would be ideal imo.

The fallback is also partly historical because it used to be the only way to configure the keys, so a server could only support one set of keys. This dynamic stuff is kinda bolted on top specifically for Transloadit's hosted use case (anyone else would just use the old way) so we want to be careful about potentially breaking self-hosters.

[mojowill]

I hope this will also work on the Transloadit plugin and not just Robodog?

[goto-bus-stop]

Yes, with the Transloadit plugin you just need a more manual configuration in each provider, since the providers cannot assume that you're using Transloadit's servers. I'll add that to the docs pages in this PR, but the short of it is:

uppy.use(GoogleDrive, {
  companionKeysParams: {
    key: 'TRANSLOADIT_KEY', // needs to be passed here because the provider plugins are not aware of transloadit
    credentialsName: 'credentials name just like in robodog options',
  }
})