Preview tokens 7: Main feature

[lukasbestle]

🚨 Merge first

• Preview tokens 6: Version-based page caching #6827
• Preview tokens 6a: Fix preview token of the site model #6828

Description

Summary of changes

It's finally time for the real thing and main attraction for this PR series. 🎉

This actually:

• adds that the token is added to all changes preview URLs,
• validates the token when auto-detecting the changes version from the request and
• uses the same implementation in $page->renderVersionFromRequest() for the draft detection in $app->resolve()

Reasoning

• General thought behind this feature: Prevent externals from accessing changes previews unless they received the full preview URL including token
• Avoid duplicated code by making the draft resolver hook into the same logic as well

Additional context

This is the first PR where it really makes sense to test it by hand as well. All "default" previews should now work. Only custom blueprint preview options that point to other pages don't work yet, those will be added in the last (smaller) PRs 8 and 9.

So for this PR, we can already test the expected behavior for:

• Site preview URL includes token and renders the homepage correctly
• Changing or omitting that token makes Kirby render the latest version instead
• Same for any page previews
• Draft previews should still work as well (with token the draft gets resolved, without token the draft 404s completely)

Changelog

Enhancements (since alphas)

• Preview URLs for changes versions now include a _token query param like draft previews. This protects those previews from access by external visitors.

Breaking changes

• Removed internal $page->isVerified() method in favor of internal $page->renderVersionFromRequest()

Docs

None

Ready?

• In-code documentation (wherever needed)
• Unit tests for fixed bug/feature
• Tests and CI checks all pass

For review team

• Add lab and/or sandbox examples (wherever helpful)
• Add changes & docs to release notes draft in Notion

[bastianallgeier]

I haven't done any manual tests yet, but I just wanted to leave a comment that the code looks really good to me. I love the idea for the new renderVersionFromRequest method to handle the verification. I was thinking if there could be an even more obvious name for it, but I cannot come up with something which would be more convincing :)

[distantnative]

Had the same thoughts but also couldn't come up with a great name. Maybe requestedRenderVersion, but it's not really much different.

[bastianallgeier]

It's an internal method, so we should probably really not waste too much energy on finding a better name when the current one is already perfectly ok.

[bastianallgeier]

Ok, I just went through the suggested test scenarios and they all work as expected. I would merge this and then fix issues if we still encounter some.