I'm on web hosted so current version 3.37.0
I have a Rest api resource I use in Workflows, it uses custom auth based on OAuth 2.0. The resource is authenticated and has a refresh auth workflow. This resource works perfectly well in the IDE and in remotely triggered workflows, unless the resource is used as part of a "Loop" block. In this case it gives an "Error: The authentication rules specified on resource 'Xero - Dummy' requires user intervention to authenticate - so it was not able to be authenticated headlessly. Please try to configure a headless form of authentication. Message: undefined (line 6)" error!
Most of the time the resource in question will accept and respond with batches of data so I only need to call it once per workflow step, however for one aspect (payment allocations) it needs to be called multiple times, hence why I'm using a Loop. For reference I've successfully used a manually coded loop in an App but I don't want to have to use an app for this use case & it shouldn't be a different experience.
Hey @mawdo81 The limitation you're seeing is expected behavior. Resources with user-specific authentication shouldn't be supported in Workflows since Workflows will run in a user-less context when triggered from a webhook or from a scheduled run.
Most Resources that rely on user-specific authentication can't be selected within a workflow to avoid this confusion. However it looks like Resources with user-specific authentication configured within Custom Auth aren't gated like this.
This resource works perfectly well in the IDE and in remotely triggered workflows
Could you clarify how you're triggering these workflows remotely in the scenarios where requests with this resource are successful?
So the resource needs user interaction for initial auth, but not for refreshing the token etc.
It turns out that today I've only been using that resource in Workflows where I'm running one off specific tasks so I hadn't had anything trigger remotely yet. To check that though I've just created a workflow that calls that resource and put it on a 1 min schedule and it was running perfectly as expected. (I've since disabled it as no need to burn through my usage.
My use case REQUIRES this resource to be callable from workflows, so PLEASE DO NOT prevent that. I just would have expected to be able to use anything in a loop block in the same way that I can in standard resource query blocks.
Without sharing any specific credentials, could you share how authentication is configured on the Resource? Please don't share any values set specific to your external data source, just which fields are filled out or not and which options selected.
In credentials there's the base URL & 3 headers, everything else is blank
It uses Custom Auth with 5 steps:
- OAuth2 (Generic) Audience is blank, rest is completed
- Define a Variable - grabs the access token
- API Request - Get with a Header
- Define a Variable - grabs the tenantID from the API request
- Define a Variable - grabs the refresh token from step 1
Refresh auth workflow has 3 steps:
- API Request - Post with a Header & x-www-form-urlencoded body with 2 params
- Define a Variable - grabs the access token
- Define a Variable - grabs the new refresh token from step 1
Auth trigger is login test URL with a simple GET formatted as per the credentials of the resource
Run this custom auth workflow without prompting the user is ticked true, the other options are not.
HTHs
@mawdo81 I haven't been able to reproduce what you're seeing. If I run a Workflow with a Resource configured with Oauth2-based Custom Auth, I see:
The authentication rules specified on resource 'MY RESOURCE' requires user intervention to authenticate - so it was not able to be authenticated headlessly. Please try to configure a headless form of authentication.
Request with Resources requiring user-specific authentication aren't supported in Workflows. You'll need to create a new Resource configured with a headless form of Authentication for this Workflows use case?
That's a massive gap...if this approach stops working as is I'd have to dump ReTool. Clearly a workflow can't ask a user to authenticate a resource, but it should be able to use a resource that has already been authenticated and kick off appropriate (headless) re-auth flows.
Where there re-auth fails then clearly the workflow would fail, but where it succeeds, what's the issue?
Hey @mawdo81, just as a followup, we have an internal ticket tracking this and we've linked your interest / use case to it. I'll update this thread as I get any new information on custom authenticated resources being supported in workflows.
1 Like
