Connect: use integrations signed in as your users #441
Replies: 3 comments
-
A related piece of work is a change to how OAuth integrations are added to your Jobs. Currently you can either add the code first then connect, or connect and then write the code. I suggest we make it so the only way to connect using OAuth is to add the code first, then follow the steps in the dashboard to do the auth flow. This will simplify things but critically it will unify things for the Connect flows above. |
Beta Was this translation helpful? Give feedback.
-
"...Work will start on it in a month or two..." |
Beta Was this translation helpful? Give feedback.
-
Initial support for being able to make requests using your users auth has been shipped as "Bring your own Auth": https://trigger.dev/docs/documentation/guides/using-integrations-byo-auth |
Beta Was this translation helpful? Give feedback.
-
When you're using integrations in the current version of Trigger.dev, you need to be the owner of the associated accounts. For example, you can use our GitHub integration using your GitHub personal access token or login to your account with OAuth in our dashboard.
This is great for a lot of use cases, but sometimes you want to be authenticated with services as your users. Some examples:
Basically you want to add integrations to your product.
What would the developer experience be?
Authenticating your users with APIs
The exact structure of the React components is TBD.
For API keys this would show a form. OAuth would take them through the OAuth flow. The UI would be "headless", meaning it would have no styles so you can style it how you wish. We'll provide some examples to make it easier to get started. Some APIs require extra information, like Shopify which needs a Shop URL. We'll automatically render these in the form and collect the required data.
Writing Jobs
They would be very similar to normal Jobs.
When you declare an integration, you'd add the
connect
option:When a Job is run the authentication details get injected immediately before
run()
is called. This is how it currently works for OAuth (as the underlying access tokens get refreshed so change over time). Currently for API keys, we never get sent them. But for integrations withconnect: true
we would store your user's API keys, like we do OAuth tokens. It's worth noting that all credentials are encrypted at rest, and all endpoints use HTTPS.You write Jobs exactly like before. Integrations with
connect
enabled would be associated with the user's account. Also you'll be able to get theaccountId
inside the Job.Triggering Jobs
This would work slightly differently, as runs need to be associated with a user.
eventTrigger (sendEvent)
This sendEvent would trigger the Job above, and cause a run as your user (with userId "123").
Webhooks
You'll need to register your user somewhere for the webhook. Then we'll subscribe to them for you.
Somewhere else in your code:
You could also register for this dynamic trigger in another job.
Using authenticated clients outside of Jobs
You'll be able to use the authenticated clients outside of Jobs. This is useful when you want to show UI in your app. In our example above, we need to allow the user to select their preferred Slack channel to receive notifications.
What changes to Trigger.dev are required to support this?
cloneForRun
method needs support for API keys from the backend.Beta Was this translation helpful? Give feedback.
All reactions