Bearer tokens with the HTTP adaptor

Job Writing
1

Hello all -
I’m having trouble using Bearer tokens with the HTTP adaptor on OpenFn 2.4.2. Specifically, the HTTP adaptor seems to be overwriting the Authorization header, even when I set the header’s value explicitly.

This is the relevant portion of my job

post('/myEndpoint', {
  body: state.data,
  headers: {
    'Content-Type': 'text/plain; charset=utf-8',
    'Accept': 'application/json',
    'Authorization': `Bearer: ${state.configuration.password}`
  }
})

When I examine the request on the receiving side, I see a Basic auth configuration, indicating that Lightning is defaulting to using the username/password combination in my credential. If I rename the custom Authorization header (e.g., Bob), that header is successfully received downstream.

I feel like I’m missing something simple and I’d appreciate some pro tips.

Thank you!
Benson

2

@bensonmiller the second portion of your code is not utilizing the state function properly, as it lacks the function arrow => to properly access the state object.
Please try this updated version of your code :point_down:

post("/myEndpoint", (state) => ({
  body: state.data,
  headers: {
    "Content-Type": "text/plain; charset=utf-8",
    Accept: "application/json",
    Authorization: `Bearer: ${state.configuration.password}`,
  },
}));
1 Like
3

Hi Benson!

@mtuchi’s comment is correct - you need to ensure you’re nesting that whole object in a function in order for the state reference to resolve correctly. Check out this section (and the lazy state operator bit) in our new Job Writing Guide for more details on that: Job Writing Guide | OpenFn/docs

But your example gave me a couple of worries, so we’ve just released a 6.2.1 version of the http adaptor which:

  • Introduces a token config option, which I recommend you use instead of password. token doesn’t do anything for you, so you still need to use those same headers
  • Makes username and password optional properties on the configuration schema
  • Fixes a little issue where we sometimes overwrite the Authorization header (!)

The 6.2.1 version should show up on Lightning soon - but in the meantime I think Mutchi’s solution should get you there.

Thanks and good luck!

4

@bensonmiller , just FYI http@6.2.1 should now be available in your instance

5

Fantastic! Thank you for the clarification @mtuchi, and for the turnaround on http@6.2.1 @jclark and @taylordowns2000!