HTTP adaptor issue: http posting to localhost instead of using credentials

When I run a job that uses the http adaptor and DHIS2 credentials defined in the portal, the HTTP POST is incorrectly made to localhost rather than my DHIS2 server.

This code for the job is here

and this is the error message:

╭─────────────────────────────────────────────╮
│ ◲ ◱  @openfn/core#v1.4.5 (Node.js v14.18.1) │
│ ◳ ◰            @openfn/language-http@3.1.11 │
╰─────────────────────────────────────────────╯
Error: connect ECONNREFUSED 127.0.0.1:80
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1159:16) {
  errno: -111,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 80,
  config: {
    url: '/api/metadata?classKey=ORGANISATION_UNIT',
    method: 'post',
...

Hi @dsurrao. Thanks for flagging this.

Could you share the structure of your credentials please (without the values). I want to make sure it uses the same structure as what language-http expect.

When using that adaptor mostly, you should have a baseUrl that should be your base endpoint. An example could typically be like this below:

{
  "username": "myUsername",
  "password": "supersecret",
  "baseUrl": "https://endpoint@instance.com",
  "authType": "digest"
}

and then you could make your different calls to post

post('/api/endpoint1, {...})

post('/api/endpoint2, {...})

Let me know if this helps.

1 Like

Also, in case it’s helpful: language-http/Utils.js at b1b4e6fc9079cdfd452d982d5e9f378e806204f4 · OpenFn/language-http · GitHub

Line 5 there shows us how configuration.baseUrl should become a proper url. Pay special attention to the /… looks like you should either have a / in your baseUrl or a / in your path… before “api” here. @Mamadou , wouldn’t it be nice if this adaptor smoothed out / related issues between baseUrl and path automagically? :mage:

Final question for @dsurrao , is this being run on OpenFn.org, or directly using OpenFn/core (or OpenFn/devtools execute or something like that)?

@Mamadou, the logs show the following:

auth: {
      username: '....',
      password: '....',
      sendImmediately: true
    }
    ...
   _currentUrl: 'http:/api/metadata?classKey=ORGANISATION_UNIT',

This is a screenshot of the settings I have on OpenFn.org:

@taylordowns2000 I tried the following combinations of urls with the same result:

  • base url with “/” and “api”
  • base url without “/” and “/api”

This job is being run on OpenFn.org

oooh! that’s a dhis2 credential you’re using, not an http credential. you can definitely write a job that works for the http adaptor but uses a dhis2 credential, but you’ll need to do things differently. I’m in transit right now. if @Mamadou doesn’t sort you out in the meantime I can take a peek shortly.

Credentials are how state.configuration gets built on OpenFn.org. There are lots of credential types and they usually match up with adaptor types. They’re quite similar, but just as different systems require different things for authentication, different credentials create different state.configurations

1 Like

Got it, thanks! I changed this to an http credential and it worked.

Incidentally, the old configuration of a dhis2 credential used to work, I had successfully run a job on 8/17.

But I’ll use the http credential going forward.

1 Like

Interesting. I’d need to check the diff on those various adaptor versions — there may have been more overlap between them earlier, or the urls in the job could have used a full url rather than just a path. Either way, glad you figured it out!

Nice here! Sorry @dsurrao I (wrongly) assumed it was run locally and not in openfn.org. But yeah, we might need to document also when to use which type of credential.
@taylordowns2000 thanks for jumping here :slight_smile: To answer your question, yes I think we should handle /in the adaptor to be more rigorous over there in case anyone forget to add it while writing a job.

1 Like