Cms: Tokenized Live Preview authorization

[brandonkelly]

It’s currently not possible to view Live Preview for an entry if its URL lives on a different domain. (Subdomains work, though.)

Live Preview requests should handle authorization with tokens rather than active user session, to enable cross-domain LP requests.

Also, craft\web\Controller should override beforeAction() and set $this->enableCsrfValidation = false for LP requests.

[acehead]

We would really appreciate if this issue gets resolved. With introduction of the sites concept (in addition to localizations in Craft 2) it is rather essential to support Live preview for sites having absolutely independent domains.

We heavily use multisite functionality and our content editors are really looking forward using Live preview without limitations.

[mrw]

Adding my vote for this as well. The cross-domain issue is definitely one big part because of the localizations/sites/etc.

The other nice thing about having tokens in the URLS is, per #1758, that would let us whiteliste live preview requests in firewalls like Cloudflare etc. Right now the POST request looks like a bunch of XSS and SQLi attempts so can get blocked. Without a token we have to turn those rules off globally.

Thanks!

[croxton]

Just a quick note to help anyone looking for live previews that work across root domains. Thanks to aliases (specifically, @web) you can do this:

https://gist.github.com/croxton/68bf8eaaba776230aed8ec7f5eeaba27

Caveat: an authenticated user could spoof the $_POST variables to load a different site's templates at a given domain, which could cause problems like cache-poisoning.

[timkelty]

Wondering if tokenizing live preview might also lend itself to the possibility of live preview data existing somewhere other than just the POST (db, cache?), so it can be intercepted by other mechanisms (e.g. https://github.com/markhuot/craftql/issues/31)

SPAs using headless Craft certainly seem to be becoming more of a "thing", so it might be nice to think about a way to extend the possibility of live preview to those implementations.

[narration-sd]

Already on the way, Tim. I'm at 99% of a solution, completing the doc on
vuepress engine and store release business to go.

It does element api and craftql, and could be adapted to changes like this,
being composed with a rather large number of adaptors worked out already
that make it practical -- and have tracked Craft design fluidity already.

Live Vue... Smooth headless live preview, spa app startup speed gains, and
so forth

I've been winding down from one more evening this week polishing some last
aspects of its Vue-side but actually any js-intended interface objects,
those making it most transparent to use, thus also support. The basis has
been solid a long time.

It wasn't something to be done over a weekend, to solve the actually quite
complex job with necessary dependability and smoothness, but I think
patience will be rewarded.

Cheers,
Clive

On Thu, Aug 2, 2018, 04:29 Tim Kelty [e-mail] wrote:

Wondering if tokenizing live preview might also lend itself to the
possibility of live preview data existing somewhere other than just the
POST (db, cache?), so it can be intercepted by other mechanisms (e.g.
markhuot/craftql#31 https://github.com/markhuot/craftql/issues/31)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/craftcms/cms/issues/1521#issuecomment-409895388, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAPIiRj8NsHb9yY1fyY1ANi8Ac3Cq31Zks5uMuK2gaJpZM4Mb5o1
.

[timkelty]

@narration-sd fantastic news, thanks for the update!

[brandonkelly]

This has been implemented for 3.1 (1ab6b6e6e3cd5a13c949d113c8367e7faf930ee4).

@mrw Current implementation puts the token in the POST body data, rather than a query string param. Is that something you’ll be able to detect from Cloudflare? I can move it if need be.

[timkelty]

@brandonkelly would a Authorization: bearer {token} header make sense here?

[brandonkelly]

@timkelty probably not, as Craft tokens aren’t used for authentication; they’re more like secret routes.

[brandonkelly]

We investigated Cloudflare/CloudFront a bit and found it a bit cumbersome to detect body params when writing bypass rules. Put it there to begin with in case templates have any logic based on query string params – having a token in the query string would be one more thing they’d need to start working around to make templates work correctly for Live Preview. So instead of putting it there, we decided to pass it as an X-Craft-Token param, which will be easy to check for in bypass rules.