task/CDD 1379 page previews

[jeanpierrefouche-ukhsa]

Description

CDD-1379 - Page Previews

Depends Upon: Front End branch: task/CDD-1379-page-previews (please pull the latest)

Date: 2026-02-27

Ticket: https://ukhsa.atlassian.net/browse/CDD-1379?search_id=055fe61d-bee9-48d9-80bc-ffb0f1c26b76&referrer=quick-find

Authors: Jean-Pierre Fouche

Impact: Affects all pages - broad testing required

Testing: Comprehensive unit tests supplied. UAT needed.

Summary

Allow editors of headless composite pages to click a Preview button that immediately redirects them to the external frontend application, rather than opening the built-in Wagtail iframe preview. Preview URLs include a short-lived signed token so the frontend can safely fetch draft content from the CMS.

Additionally, allow users to select an embargo date in order to preview otherwise embargoed data.

Continued in ./changelog/2026-02-27/CDD-1379.page-previews.md

Fixes #CDD-1379

---

Type of change

Please select the options that are relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Tech debt item (this is focused solely on addressing any relevant technical debt)

---

Checklist:

• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests at the right levels to prove my change is effective
• I have added screenshots or screen grabs where appropriate
• I have added docstrings in the correct style (google)

[jrdh]

I've made lots of comments but this is looking really good! Worked nicely on my local machine 🙂

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
1 Accepted issue

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jrdh]

Still looking good. Made a few comments in line but nothing major there. I have concern which I think we have to fix and a question.

The concern is that I think the /nocache/ functionality should be protected by the same method we're using for the /preview/ URLs (i.e. signing) as without any authentication on them they allow access to potentially unembargoed data and open up endpoints malicious users could DDOS us with due to the uncached nature of the responses.

The question is whether you considered using the Django request context instead of the ContextVars? I don't have a strong feeling either way but wasn't sure if there was a best practice method Django recommended for variables that live for the length of a request and need to be passed around to different functions? The only issues I could foresee is if Django actually uses multiple threads to respond to a request and doesn't copy the context over which would mean the embargo date wouldn't always be set correctly. I think this is really unlikely but just wanted to raise it as a concern related to what Django best practice is.

As an aside, I would have much preferred if this had been worked on in a series of commits rather than one fat one. It's not good for future maintainability/the git history, and it makes it much harder to review as I can't just look at the new commits created after my last review.

[jeanpierrefouche-ukhsa]

The question is whether you considered using the Django request context instead of the ContextVars? I don't have a strong feeling either way but wasn't sure if there was a best practice method Django recommended for variables that live for the length of a request and need to be passed around to different functions? The only issues I could foresee is if Django actually uses multiple threads to respond to a request and doesn't copy the context over which would mean the embargo date wouldn't always be set correctly. I think this is really unlikely but just wanted to raise it as a concern related to what Django best practice is.

Hi Josh,

Thanks for your comment.

Yes, Django request context was considered and I appreciate that it is often the go-to approach in Django. However, Django request context needs to be passed around. This would break all of the code interfaces (signatures) and make the application more complicated. ContextVars allow the code to pull in request-scoped state, without passing state around. A few points about ContextVars:

• they are safe (won't leak) within the execution context (which is deeper than just the thread. See Python Docs on ContextVar, the section on asyncio support
• if spawning a new thread, the onus is now placed upon the thread creator to use ContextVar.copy_context. Note that this is an edge case, in which the thread creator needs access to embargo_time. In my view, this is cleaner, relatively simpler, and more reliable than passing Django request state around explicitly. Anybody spawning a new thread should, in any case, reasonably assume that there are going to be issues with accessing state and take appropriate steps to ensure access.

Example code, below:

import threading
import contextvars

embargo_date = contextvars.ContextVar("embargo_date")

def worker():
    # ContextVar is available here (current execution context, current thread)
    print(embargo_date.get())


def start_thread():
    embargo_date.set("2026-05-14")

    # Capture current context
    ctx = contextvars.copy_context() # <================== use copy_context if you need the embargo_date

    # Run worker inside copied context
    thread = threading.Thread(target=lambda: ctx.run(worker))  # <===== run a thread within the context
    thread.start()
    thread.join()
    ```

[jeanpierrefouche-ukhsa]

The concern is that I think the /nocache/ functionality should be protected by the same method we're using for the /preview/ URLs (i.e. signing) as without any authentication on them they allow access to potentially unembargoed data and open up endpoints malicious users could DDOS us with due to the uncached nature of the responses.

Hi Josh,

I have reworked the flow so that routes to "View Live" are now authenticated.
Please see the changes for your review.

Many Thanks!

@jrdh

[jeanpierrefouche-ukhsa]

As an aside, I would have much preferred if this had been worked on in a series of commits rather than one fat one. It's not good for future maintainability/the git history, and it makes it much harder to review as I can't just look at the new commits created after my last review.

Hi Josh,

Yes, I can see where you are coming from! In a large commit like this it must have been less than helpful having to do the second review, not having a baseline to review it against.

@jrdh

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jrdh]

Looks good, thanks for making those changes JP 🎉

Couple of minor comments in line and a question:

• If I remove the page_id or change it to a different valid value (e.g. the ID of another page) from either /preview or /nocache URLs it still works fine - is this intended? If so do we need that query parameter?

Otherwise, this is good to go to QA as far as I'm concerned!

[jrdh]

Any particular functional reason to default to nocache here instead of error if the route parameter isn't set?

[jrdh]

Extremely minor note, because we expose /admin as /cms-admin, the URL path starts cms-admin not admin.