ODK Central with custom database with SSL

@Florian_May, that PR is now merged! I think you can go ahead and deploy that change to your production server. Since you downgraded your production server to v1.1, you might also need to redo the special instructions for upgrading to v1.2 (not sure).

Even though the PR is merged into the master branch, you should not use the master branch on your server, as the branch contains commits that have not gone through QA. Instead, you should use origin/db-connect. If your server is on the commit 93732a496bc9daa40cdbb36247c908649a96f10a, you should be all set.

I think we'd be open to a PR or a detailed issue along those lines. I'm thinking that this header would be needed for both backend responses and frontend resources? If so, I'm guessing that the header would probably go in the nginx configuration in the central repository. But I also know that there are a few different caching-related headers; not sure whether any of those would need to be changed as well.

This seems farther off the beaten path compared to the standard Central configuration, but I think we'd be open to a PR along these lines. As a first step, if you want to create a detailed issue in the central repository, that'd be a good way for us to think more about the approach.

I'll note that Slonik and Knex seem to accept certificate options in different ways: Slonik wants a filename, while Knex wants the file contents. And like you said, in order for the backend to be able to access the file, the Docker setup would probably need to change. So both the central and central-backend repositories would need to change.

But I'm also wondering, given that Slonik will always specify false for rejectUnauthorized when SSL is specified, is there much benefit to specifying the certificate at this point? Maybe Slonik would need to change first?

In any case, I'm glad your server can connect to the database now! :rocket:

Thanks @Matthew_White1

My prod server is already happily running the db-connect branch - had to upgrade as soon as UAT showed it works, as the db (already migrated to 1.2) vs the 1.1. frontend gave me trouble.

PROD: tagged frontend with db-connect backend.

versions:
e16b79530756bbd825f68275b3b6e53951409474
 70ec99f02885a06e37709db6319bfdf96fac84eb client (v1.2.2)
+93732a496bc9daa40cdbb36247c908649a96f10a server (v1.2.1-4-g93732a4)

UAT: latest master frontend, db-connect backend.

versions:
e16b79530756bbd825f68275b3b6e53951409474
+9d97de6397317dc4ce046d60cbb2ccaf4e967f40 client (v1.2.2-14-g9d97de63)
+93732a496bc9daa40cdbb36247c908649a96f10a server (v1.2.1-4-g93732a4)

re caching headers
Disabling caching for the backend API could work but I'm unclear on how caching in VueJS works.
Let me talk to my IT folks and see which headers should go where. If I find a robust suggestion, I'll send a PR.

re SSL certificate
Since our DB and VMs running Central are well protected from the outside world, we're good with ignoring SSL. I just thought it might be safer to specify a certificate, rather than to ignore a safety feature.
Out of interest: I see Central uses two different ORM libraries (knex and slonik), which makes things like configuration options harder. Could Central migrate to just one?

1 Like

We've mostly moved from Knex to Slonik and generally like Slonik. However, Slonik doesn't have its own migration mechanism, so we've continued to use Knex for that. Mostly that's been fine, though like you said, configuration has turned out to be a challenge. I do think it'd be a significant effort to move away from Knex though.

1 Like

As an update, this functionality is now available as part of v1.3. Thank you for all your help troubleshooting this issue!

1 Like