Support PAT for DHIS2

[taylordowns2000]

@FaraiMutero , if PAT support is important for the DHIS2 community I think this is where it would need to end up

1. add an optional Personal Access Token field to the configuration schema for dhis2 here - https://github.com/OpenFn/adaptors/blob/main/packages/dhis2/configuration-schema.json
2. then add some logic here that uses a PAT if provided, but defaults back to username/password if there's not PAT - https://github.com/OpenFn/adaptors/blob/main/packages/dhis2/src/Client.js#L15

One more Q here: how about Oauth2? We support generic Oauth2 clients, so maybe we should also extend the DHIS2 adaptor to support Oauth2

[FaraiMutero]

Hey @taylordowns2000! Thank you so much for logging this issue. I think the big issue is that now within the DHIS2 Dev Community PATs are now essentially the gold standard both for dev and production use cases. So from a security perspective, the use of the DHIS2 username and password is now just as a last resort when all fails. A quick alternative which would be immediately useful to the DHIS2 community would be perhaps a vanilla adaptor that allows one to specify custom headers. This is because applying the DHIS2 PAT is essentially including an "Authorization Header" with the value "ApiToken {secret_token_value}" (see attached screen-grab). I even mentioned to my team this morning that if Taylor can show me how to do it, I can implement it immediately!

[taylordowns2000]

A quick alternative which would be immediately useful to the DHIS2 community would be perhaps a vanilla adaptor that allows one to specify custom headers.

This already possible using the HTTP adaptor, or (correct me if I'm wrong @mtuchi or @josephjclark) the current DHIS2 adaptor.

Most of the adaptors allow you to specify request options. If you've set up your PAT as the value for some key in a raw JSON credential I see no reason why you couldn't send that as a custom header.

Extending the DHIS2 credential to expect this, however, wouldn't take much doing.

[FaraiMutero]

Thanks @taylordowns2000, I agree extending the DHIS2 credential would be first prize, so that we also can benefit from magic functions as well when building the workflow. Any rough estimate ETA for this so that I can give feedback to the team?

[josephjclark]

I've just had a quick look... the docs aren't terribly helpful but there are get and update functions: https://docs.openfn.org/adaptors/packages/dhis2-docs#get

The options.requestConfig key gets fed straight into axios, so you can set the headers key to what you need.

get(
  'trackedEntityInstances`,
  { program, orgUnit },
  {
    requestConfig: {
      headers: { Authorization: `ApiToken abc` }
   }
})

You might also need to set Content-Type to application/json.

[FaraiMutero]

Thanks @josephjclark. This is great, I will try that out!

[taylordowns2000]

Ah, depends I suppose. I'm on a phone now so can't actually implement the code changes, but if you added an optional field in the schema (see link in point 1 at the top of this thread) then added an "if (configuration.pat) then..." line to the link in point 2, that should do it.

I'm assuming these 4-5 lines of code will take less than 5 min to implement, but you'll then need a dhis2 system to test with and you'll need to be able to run pnpm build and then use the OpenFn cli (npm install @openfn/cli then here for docs) to test whether or not it's actually working the way you want.

Assuming it all works, I'd request that you add a test to show that the configuration handler works for both creds with a PAT and those with basic username/password auth.

Has anyone on your team worked with OpenFn adaptors before? Or have JavaScript familiarity? It would be super useful for them to provide feedback on what's hard if they have trouble cloning this repo and getting up and running. Thanks so much for considering this 😊

[FaraiMutero]

Thanks @taylordowns2000. We are still early in our OpenFn adoption, and I'm leading that effort. I setup my local instance via docker at the Jembi Summit a month ago. I'm currently using the out-of-the-box functionality at this stage, and had not yet reached OpenFn adaptor configuaration / customization stage. However let me run some local tests and I will return to this thread with some feedback. Many thanks for the support!