Skip to content

Password-Protected Previews

A site whose mode is demo (or restricted) is hidden behind a password until it goes live. It is how a prospect or a new customer sees their site before launch: every page sends the visitor to /demoLogin, and once they enter the site's demo password a cookie lets them in. The mode and the password are set on the tenant under System > Tenants.

What a visitor without the password gets:

  • every page redirects to /demoLogin?o=<the page they asked for>; only /demoLogin, /demoAuth and /.well-known/* are open;
  • the hosts that serve previews (*.bdgr-demo.co.uk and the other non-indexable hosts) answer every response, redirects included, with X-Robots-Tag: noindex, nofollow, and the login page carries the robots meta tag itself, so nothing on a preview reaches a search engine.

Most people who are sent a preview will not get past a password form, so a link can carry the password and skip it:

https://acme.bdgr-demo.co.uk/demoLogin?key=<demo password>&o=/donate
  • key is the site's demo password. When it matches, the visitor gets the same cookie as the form sets and is redirected straight to o (the home page when o is left out).
  • A wrong key redirects to the normal login form with the usual "incorrect password" message, and says nothing about why.
  • o must be a path on the same site: it has to start with a single /. Anything else (another host, //host, /\host, a scheme, CR/LF) is ignored and the visitor goes to the home page. The same check now applies to the form's return path.
  • The link always answers with a redirect, so the key does not stay in the address bar of the page the visitor lands on. The redirect is sent with Referrer-Policy: no-referrer (the key is never passed to the next page or a third party as a Referer) and Cache-Control: no-store.
  • The application never logs the key: it has no access log or request-logging filter, and the controller logs only the site id on a wrong key. (The CDN in front of the cluster sees full URLs, as it does for every request.)

It is short enough for a QR code: put one on a collection-bucket mock-up pointing at the donate page and the scan lands on the page itself.

The link carries the real password. Anyone with the link can see the preview, which is the point, but treat it like the password: send it only to the people it is meant for. To cut off every link and every browser that has used one, change the demo password; the cookie is bound to it.

The cookie lasts 30 days, so someone who opened the link can come back to it before a meeting.

The preview badge

A site in demo mode shows a small fixed badge in the bottom-left corner of every storefront page: "Preview site · test payments only, no card is charged" while its Stripe account is not live, and "Preview site · not live yet" once it is. It is click-through, so it never blocks the page beneath it, and it disappears when the site's mode changes. restricted sites (private but live) do not show it.

StorefrontChromeInterceptor sets sitePreview and sitePreviewTestPayments on the model; every theme's footer includes fragment/preview-banner (one file in bootstrap/, found by the default-theme leg of the resolver chain). The text is nav.preview.badge and nav.preview.badge.testPayments.

Payments on a preview follow the site's Stripe account, as on a live site: until the account is live, checkout uses Stripe test mode and says so on the payment step. Test card 4242 4242 4242 4242, any future expiry date and any CVC completes a test payment.

Code

  • DemoServiceImpl (commerce-core): the gate and the cookie.
  • DemoModeController (web-mvc): /demoLogin (the form, and share links) and /demoAuth (the form's post).