Provide demo-triage sites for multiple versions
Goal
Provide demo sites for several recent versions. At time of writing, that would mean (say) 5.59-rc
, 5.58-stable
, 5.57
, 5.56
, and so on (perhaps going back 6-9 months).
Motivation
The current demo sites are often used to determine whether a bug is easy to reproduce. However, there is another common question when triaging a bug: When was the bug introduced? (This helps you determine the specific cause and helps to establish the priority for the bug.)
Even for somebody who has a local dev system and knows how to switch around builds, it usually takes 5+ minutes just to setup an environment for evaluating the bug on one specific version. For folks with fewer resources, it may take longer or be impossible.
Obstacle
The main reason we haven't done this is security -- if you run a 9 month old version, then the odds are that it has some known/published security vulnerabilities. Of course, I don't think we should worry that Civi contributors will abuse such sites. The problem is about creating an easy target for bots and scriptkids.
We want to find a simple way to facilitate triage while keeping out the riffraff.
Brainstorming Solutions (Dislike)
- HTTP Basic (Static/Shared): If it leaks to the riffraff, then it's easy to abuse. Changing is a problem for anyone who uses the system. Also, it obfuscates testing of Civi-CMS functionality that involves HTTP Basic.
-
HTTP Basic (LDAP/civicrm.org): I don't think we should submit real
civicrm.org
credentials directly to a hackable box. Also, it obfuscates testing of Civi-CMS functionality that involves HTTP Basic. - Port Knocking: Same leakage problem as "HTTP Basic (Static/Shared)". Also, fairly obscure.
Brainstorming Solutions (Like)
-
OpenID Connect: If you try to access an older demo site, it redirects to a web-page that shows a warning and does some kind of identity check (e.g.
civicrm.org
account orgithub.com
account orcontributer-key.yml
entry). Then it redirects back and sets a cookie. (The access cookie should be separate from the one usually used by PHP/CMS/Civi.)- Good: No special setup on the user's workstation. Just a redirect in the web-browser.
-
Bad: Only works well in web-browser. Using
curl
,mysql
, etc is annoying.
-
Private Network: Put older demos on a private network. Connect through some kind of VPN (e.g. "IKEv2", "OpenVPN") or mesh overlay (e.g. "Tailscale", "Nebula").
- Good: Works with most tools+protocols (browser, curl, mailcatcher, mysql, etc)
- Bad: Requires special setup on workstation. Public wifi (cafe/library/train/etc) may block access.