Modernize to Rails 8 / Ruby 3.2, add tests, security fixes, and turnkey Docker

[kltm]

Status: WIP / draft — for evaluation, not yet ready to merge.

This modernizes the License Server end-to-end and packages it so it can be stood
up with a single command for evaluation. It is an in-place upgrade, so the
diff stays reviewable.

What's in this PR (4 commits)

1. Rails 5.1.7 → 8.0.3, Ruby 2.7.8 → 3.2.9 — ontologies_api_client → its
   GitHub tag v2.9.0; puma instead of Passenger; the Sprockets pipeline is
   retained (sprockets-rails); uglifier → terser; turbolinks/coffee dropped.
2. A Minitest test harness — the app previously had no working tests. Covers
   the license-key crypto contract, the License date / latest_licenses
   helpers, login + access control (anon / owner / admin), and the
   approve → key → email flow. The two BioPortal API calls are stubbed.
3. Security fixes — CSRF re-enabled; explicit strong params replace
   params.permit! (this also closes a privilege escalation: a non-admin could
   POST approval_status=approved and have a license key issued); the
   user-scoped SQL is parameterized.
4. Turnkey Docker — docker compose up brings up app + MySQL + memcached,
   auto-migrates/seeds, and serves puma on :3000. Config is ENV-driven; no
   secrets are baked into the image.

The license-key format is unchanged and verified byte-stable across the
OpenSSL 1.1 → 3 jump, so appliances in the field keep validating keys minted by
the upgraded server. (Issue #34's signature rework is intentionally out of scope.)

Try it

BP_REST_URL=<your BioPortal REST API> API_KEY=<your API key> docker compose up --build
# then open http://localhost:3000 and log in with BioPortal credentials

Run the test suite (the production image is slim, so this re-adds the test gems):

docker compose run --rm -e RAILS_ENV=test app \
  bash -lc 'BUNDLE_WITHOUT= bundle install && BUNDLE_WITHOUT= bin/rails test'
# => 13 runs, 50 assertions, 0 failures

Still open (why this is a draft)

• Runtime secrets for a real deploy: SECRET_KEY_BASE, the production RSA signing
  key (mount + PRIVATE_KEY_FILE), SMTP. The container generates ephemeral dev
  versions, with warnings, when these are absent.
• Reconciling the existing Capistrano deploy with the Docker path, and how the
  whenever expiry-notification cron should run in a container.
• A few deferred tests and a Dalli protocol deprecation warning.

Feedback on the overall approach is very welcome.

— Posted by Claude Code agent on behalf of @kltm.

[kltm]

@jvendetti I was wondering if I was on the right path here (developing on Ubuntu 24.04). I was wondering if you could take a quick look at this for me; running would look like:

BP_REST_URL="XYZ" API_KEY="ABC" docker compose up --build

[jvendetti]

Hi @kltm - sure, took a quick look and this seems like the right path. I was able to run the compose command you listed to bring up the license server and login with my BP account:

[kltm]

Great--thank you for taking a look at it. I'm going to poke at it a little more, but I think there may be enough there to me usable. I'll try and figure out a better way to test.

[kltm]

A note to clarify deployment, since this PR adds a Docker path alongside the existing Capistrano setup. Choosing between them is an NCBO decision — this PR deliberately doesn't settle it.

• Existing Capistrano + Passenger deploy (config/deploy.rb, .github/workflows/deploy.yml) is left unchanged. The app code is upgraded to Rails 8 (which Passenger supports), but this PR has not exercised the Capistrano/Passenger path end-to-end — only the Docker path is verified here.
• New Docker path (docker compose up) runs the app on puma and is the one validated in this PR.

Two things to be aware of if you adopt Docker for production:

1. Runtime secrets/keys — provide SECRET_KEY_BASE, the real RSA signing key (mount it and set PRIVATE_KEY_FILE), and SMTP settings. Without these the container generates ephemeral dev values (with warnings) — fine for evaluation, not for production licensing.
2. The nightly expiry-reminder cron — the whenever-generated crontab (rake batch:send_licence_to_expire_notifications) is installed by Capistrano on the app host. A plain container has no cron, so under Docker this job must be wired up separately (e.g. a small scheduler/sidecar invoking the rake task). It is not included here.

Happy to implement whichever direction you prefer.

— Posted by Claude Code agent on behalf of @kltm.

[kltm]

@jvendetti I believe that this should cover the main target (update/refresh and dockerization), as well as #20 in order to test the tests added with the refresh.