U4-11491 - Preview Pages anonymously

Created by Paul de Quant 29 Jun 2018, 12:47:24 Updated by Dallas Taylor 20 Jul 2018, 02:35:16

As part of our internal work flow, we need to create pages in our staging environment and distribute the links to third-parties in order to approve the content. These third-parties do not have logins, so it would be create if we could send them a link to the preview page.

This stems from the issue, whereby:-

You create a page on a staging site You publish it Send a link to the page to the approver/third party You make changes based on feedback You save and schedule the change to go live on a specific date You courier it to your live environment.

At present if you follow this process, you will find that the page will never publish on live. Because the previous publish does not exist in live. You'll see an message stating:-

This document is published, but not in the cache.

The easiest way around this is to have a preview page, that can be accessed by users outside of Umbraco backoffice.

Can anyone make this happen?

Cheers Paul

Comments

Pete Duncanson 03 Jul 2018, 15:10:49

I've wanted to do something like this for ages. Should be doable as the preview file is generated but currently it gets deleted. You would need to be able to opt in to save the page somehow. This could be done with a "share" button which would:

  • Generate the file as normal but flag it to be saved (possibly by appending something to the filename so we know we need to keep it around)
  • Generate a popup with a link to the page that you can share (copy to clip board would do for now)
  • If we assume a preview can exist for only 7 days then we save this data to the filename such as 1234567890_7.xml (we could allow other values or use UTC dates or similar that are X hours/days in the future).
  • When creating a preview scan the preview folder to see if there is anything we need to delete by getting all files can pulling out the UTC time of the end of file and see if its in the past. If so delete it.

That "should" do it. We might need to change the existing preview code to ensure it doesn't delete our "saved" files (which we know about due to the new meta data we stored in the filename).


Sebastiaan Janssen 11 Jul 2018, 07:03:27

I am very wary of this as I foresee a few problems:

  1. People will put the URL on social media and will "leak" things that were not supposed to be published yet (especially if you have a "Share" button in there)
  2. Performance is notoriously bad since we need to go to the database for everything, this will lead to high CPU loads, so with #1 you could easily auto-DOS yourself
  3. The link should not be guessable else everybody would be able to read your work in progress, which might have content in it that should definitely not be available before date x (I can think shareholder reports for example)
  4. We'd need to keep several copies of the XML around for an unknown amount of time - you share page 123 with Lucy on Tuesday, which she finally gets time to open on Thursday, do you show Tuesdays snapshot? you share page 234 with Anne on Wednesday, do you keep the snapshot meant for Lucy around as well? Or do you just generate them on the fly?

To slowly start to figure out the answers to these questions (and others I haven't foreseen yet) I think this would make an excellent candidate for a package that can perform this functionality. Once all the problems have had clever ways to fix them, it could be a candidate for core.

If you need any extension points for said package then make sure to open separate issues for those!


Pete Duncanson 16 Jul 2018, 12:30:40

I disagree with the logic with the official line on this one, I think it hampers the development of features like this rather than helps. But so be it.


Sebastiaan Janssen 16 Jul 2018, 13:29:29

Hey Pete, that's absolutely fine, make sure to counter with arguments and we'll happily have another look.

The most important concerns are:

  • Secure - people WILL share preview links, as they do every week today, on Twitter so how can we make sure upcoming content does not "leak"?
  • Prevent auto-DOS - how can we make sure we don't accidentally cause huge load on the server?

I'm sure we can work out non-guessable links and preview XML data, that's not the biggest problem.

We'll happily look at solutions that overcome the problems above when offered.


Sebastiaan Janssen 16 Jul 2018, 13:41:25

Please also note that, unfortunately, the current preview mechanism is rather poor and anemic, if I recall correctly, when you ask for a preview you get a preview of JUST that page and can't browse the rest of the site in preview mode.

Note that v8 is much nicer, there is always a version of the published and draft version of each page in the new NuCache implementation. So in v8 it would "just" be a matter of building a good way to share a preview.


Pete Duncanson 16 Jul 2018, 14:01:44

The two points you raise are both excellent point that need some thought, that is what issues like this are for to have those collective discussions and weed out the real issue and hopefully some solutions before any code is actually created.

Secure, we have a couple of options I can think of:

  • So what? If marketing use the wrong link despite being told its not the live url whats the problem. How is this different to them finding yet another way to upload a 300Mb image on the homepage?
  • I originally said that the previews would be time limited, say live for 24 hours or 7 days or something. My thinking here was similar to sharing a Google Doc, it gives you a time that the link can be live for. This would stop pages getting indexed etc. too.
  • Have a "read limit" on the page and if greater than X then stop serving it, this one sounds like a fudge though and opens more cans of worms about where to store the count, what page do you show them instead, etc.

Prevent auto-DOS:

  • My understanding is the page is generated from the preview XML so why are we hammering the database if thats the case? Another great example of the power of having some HQ insider knowledge on the issue.
  • If it is hammering the database then I suggest we stop it doing so if that is an option. Prehaps the reason it does so is to work around an issue that no longer exists (the preview feature hasn't had much love in a while and things change).
  • Ask users to login first, this would work nicely but would add another layer of frustration to the whole process. If you want the big boss to eye ball a page she doesn't want to have to login first just as you don't want to be bothered with being asked how to do it (or worst email around login details to prempt the inevitable question). So I'd file this as a fudge.

Alternative fudges:

  • Inject markup to let it be know its a preview, this could be as simple as adding "PREVIEW" to the title tag or a whole div in the footer or header or even injecting in noindex meta tags etc. I'd suggest we steered clear though as all of them sound a mess.
  • Change the url to something nice and clear www.example.com/do_not_share_with_public/preview/0123456789 to prevent marketing getting giddy.

On another note I dislike the idea of making a feature prove itself as a package before it will get any HQ love/input. But I'll leave that one for another day. I will say though lets try to save that recommendation for when needed and not have it become the default.


Pete Duncanson 16 Jul 2018, 14:02:24

Depending on your answers can we have this issue re-opened if you see fit.


Pete Duncanson 16 Jul 2018, 15:05:15

No one is going to create a package for V8 just yet...


Sebastiaan Janssen 17 Jul 2018, 07:41:32

I'll re-open this with a few notes:

Setting expectations: this has very low priority for HQ, to implement this feature would be a community effort

I see people posting Umbraco preview URLs once or twice a week, this will happen especially if there is an easy "share" button, no matter what the URL looks like. There is a real risk that Umbraco gets accused of revealing sensitive data - big companies use Umbraco to launch "secret" campaigns, advertise discount codes, publish yearly reports to shareholders, there may just simply be embarrassing dummy content, etc, etc. "So what?" is not the appropriate response here.

In order to implement this feature I'd suggest we need to do the research first:

  • What is the best way to make this "secure"? Maybe a one-time password that needs to be typed to unlock the content? Instead of just having a URL that anybody can copy.
  • Does Umbraco indeed lean heavily on the database to preview a single page?
  • How will this work when sending a preview to multiple pages to multiple people? Do we need to regenerate the preview XML for each, does that even work? Do we need to make multiple preview XML fragments?
  • How can we clean up after a while? What happens when someone clicks the preview URL after cleanup has happened?
  • As far as I remember, a preview is for one page, once someone starts clicking around, they will get published content again, seems like we would need to fix that situation too (this is already done in v8)

No one is going to create a package for V8 just yet...

Sure, I did not mean to suggest making a package for v8. Point was: there's very little work to do in v8 to make anonymous preview happen, in v7 it is a bigger project. For v8, all we have to figure out is a happy medium in making sure we can "securely" share preview content.


Dallas Taylor 20 Jul 2018, 02:35:16

We have had multiple clients asking if it is possible to share the preview with colleagues who do not have (or want) a login.

This issue (and discussion) reminded me of this article that makes preview accessible as a staging site - a specific hostname displays the preview content.

https://www.liquidint.com/blog/a-simple-alternative-to-umbraco-courier/


Priority: Normal

Type: Feature (request)

State: Open

Assignee:

Difficulty:

Category:

Backwards Compatible: True

Fix Submitted:

Affected versions:

Due in version:

Sprint:

Story Points:

Cycle: