Support previewing unpublished pages for L10N and review purposes - without need for user accounts

Context

There will be occasions where we need to share a page that has yet to be published, for various parties to review. Some already apparent cases include:

1) Review of new pages by members of the org that requested it (eg Marketing, Product, Legal, etc) 2) Viewing of the source-language version of a page (ie en-US) by translators working on a page.

Case 1) could be handled by adding a number of users to the CMS, with a particular custom role (eg 'Content reviewer' that allows seeing specific pages, but denies all editing, publishing and even page-tree navigation behaviour, ideally). However, this does come with the "paperwork" overhead of adding each of these people to the Wagtail admin and to the relevant people.m.o group.

Case 2) cannot reliably be handled by adding users to the CMS, because many translators do not have (and will not ever have) Mozilla SSO credentials.

As such, there's a need for a way to reveal a page that has not yet been made public, in a way that's secure/secret enough, which also does not require us to start adding session cookies to the production site.

One option is to actually publish the pages, but password-protect them and to ensure all this previewing happens on the CMS deployment (https://bedrock.cms.prod.full.domain.redacted), because that already supports session cookies.

However, this has downsides: 1) The pages will still be published, so will be available on the Web deployment. If someone tries to load them on the Web deployment (which has no cookie support) things will fail there, possibly ungracefully. 2) We'd need to further tune the sqlite DB exporter to ensure that no private pages are included in the DB export. 3) We'd have to support sharing a password with all appropriate/allowed viewers

There is, though, another option:

Proposed solution

We add support for previewing a draft page via an obfuscated URL that contains a very long, unguessable hash - similar to how Google Photos does this. This means we don't need shared authentication - if someone has the page URL, they can access it. (This relies on the special URL being handled sensibly by MoCo staff and vendors. If Legal allows, we can add access logging so we capture the IP address and user agent of whoever is viewing the page.)

The custom URL could be based on a hash of the current content of the page's fields, which means that if the page is edited, the hash would 'expire'. Or we could make it more stable and base is on factors that change less often.

The custom URL would be accessible via the main page-edit UI - most likely via the secondary page-drop-down menu

This idea needs more thinking through, but it's a general direction that might work to solve the problem

Success Criteria

[ ] An element contributing to the definition of done for the card
[ ] Tasks should be represented here as something like "Approved designs attached to this issue"

mozilla / bedrock