Header Based Authentication & Healthcheck

[latetedemelon]

Please take a look; I could use someone else to test as well if possible.

[latetedemelon]

Please let me know if any changes are required.

[jhonderson]

Hey thanks for your PR, left few comments

[jhonderson]

Actual api is initialized in actual-client-provider.js

[jhonderson]

Left few more comments, thanks!

[jhonderson]

Hey @latetedemelon, I am ready to merge this. One last question, once existing users upgrade to this new version of actual-http-api, everything will continue working out of the box right? i.e no need for them to add new environment variables to their actual-server nor actual-http-api containers.

[jhonderson]

While testing locally, I found few issues and I was able to fix them except the last one:

Fatal start-up error: TypeError: setToken is not a function
    at initializeActualClient ...\actual-http-api\src\v1\actual-client-provider.js:45:3)
    at process.processTi cksAndRejections (node:internal/process/task_queues:105:5)
    at async getActualClient (...\actual-http-api\src\v1\actual-client-provider.js:67:5)
    at async ...\actual-http-api\server.js:9:3

Is the new setToken function already in the nodejs api?

[latetedemelon]

Is the new setToken function already in the nodejs api?

My bad, it is in the actual api package

[jhonderson]

Hello Rob 🙂, I pushed a commit to simplify this PR a bit — I focused only on the changes needed for the feature to work. That way it’s easier to review and reduces the chance of regressions.

I tested both approaches and they’re working for me. The only caveat with the header approach is that I had to set ACTUAL_TRUSTED_AUTH_PROXIES=0.0.0.0/0 in my actual server, since I wasn’t sure how to allow-list just my proxy.

Hope the updates look good to you! This is still your PR, so please let me know what do you think.

Thanks,
Jhon

cc @latetedemelon