search

jhu-idc / idc-isle-dc

Islandora Digital Collections (IDC) development environment
MIT License
2 stars 6 forks source link

Migration tests fail when self-signed certificates are used #99

Open emetsger opened 3 years ago

emetsger commented 3 years ago

When the certificates used by the IDC stack are replaced with self-signed certificates, migration tests inexplicably fail. Migration tests have two components, the testcafe portion which actually performs the migration using the Migrate Source UI module, and the Go portion which verifies the expected results. The testcafe portion succeeds, but the Go portion fails. The Go portion uses the JSONAPI to retrieve the actual results, and compares them to expected results provided by the test. The failures occur when the JSONAPI representation of a resource is retrieved (a 400 is returned instead of a 200).

The certs used by the stack are not under version control (.gitignored), and reside under the certs/ directory, populated by the download-default-certs make target.

The make target is inane; for example, make -B download-default-certs doesn't force new certificates to be downloaded (you have to actually rm the files in certs in order for the make target to refresh the certificates). 🙄

The certs used by IDC are signed by a trusted CA. When the certs are replaced with a self-signed certificate, migration tests fail.

To see this in action, checkout development e75e8ff and run make reset && make test. All tests should pass.

Next, checkout the self-signed-certs branch and run make reset && make test, and you'll see that migration tests fail.

emetsger commented 3 years ago

The working theory is that when the default certs are used (the trusted ones from Let's Encrypt), the requests issued by Go to the JSONAPI go directly to the drupal container.

When the self-signed certs are used, the requests issued by Go are issued first to traefik, which then proxies them to the drupal container.

The requests issued by Go do not have their URL query parameters encoded (this is an oversight), however, drupal happily accepts those requests. When the same requests are issued through traefik, they are spiked with a 400 error (but this error is not logged at all by traefik because the magic incantation for logging them is unknown).

traefik will log 404s, for example, but not 400s that result from an unencoded url query parameter.