zesty.io

Product

Use Cases

Integrations

Learn

Security

Authentication headers and Preview Lock protects your preview URL from being freely accessed and misused.

Stage Preview Lock Protection

#

The WebEngine preview URL is locked from public consumption. As such it will only render if:

  1. The user is logged in and has access to that instance.
  2. A valid password has been provided. This password is set by via the Settings under security , a user may enter the password to start a verified session.

Any instance created on or after Jan 1, 2021 is automatically locked. If your instance is older and you would like Preview Lock Protection, please reach out to support.

Once a user is verified by (via password or their user login session), a unique device imprint cookie ZVerified is created and is used to quickly bypass the preview lock for every network request.

Preview Lock Protection exists to protect your un-published changes and to prevent users from using the preview URL in production.

Preview Lock Protection Password

For Instances created before Jan 1, 2021, contact your account manager, as you will need a setting added to your instance. Once the Preview Lock Password text field has been added your preview URL will be password protected.

Setting a Preview Lock Protection Password

When the preview URL is being accessed by non-authenticated Zesty users, you may set a Preview Lock Password which prompts an unauthenticated user to enter a password. They may try 5 times before being locked out.

Linking with a Password

If the ability to pass the preview lock password as a get parameter is required for internal sharing or for internal authenticated workflow (Jira, Private Github, Etc), then a password can be passed with the zpw query param like:

https://HASH-dev.webengine.zesty.io/?zpw=12345

where 12345 is whatever the preview lock password is. The user that opens that link will be authenticated for their browsing session, and will be able to free view the site without entering a password.

This also works for headless testing against the preview environment.

Production Authentication Headers

#

Production sites can be blocked by forcing an authorization header to be added to each request likeAuthorization: bearer [SECRET KEY] . Authorization headers can be edited in manager ui > settings > security

Headless Authorization will be applied to Instant, Headless, and GQL APIs.

Full WebEngine Authorization will be applied to every request. This setting will collide with Headless Authorization, therefore, headless authorization needs to be removed when using Full WebEngine authorization.

Adding authorization secret key reflect immediately in production site and will block public access. Pages that are already cached will need to be purged for required authentication to take effect.

Editable in Manager UI > Settings > Security

auth-key

Connect with Content Experts

Book a free 15-minute consultation with a content expert. Discuss your application, pain points and requirements. Understand how Zesty's lower total cost of ownership, features, functionality can elevate your business by creating extraordinary digital experiences.

Trusted By

zesty customer logo Sonyzesty customer logo Rocket Leaguezesty customer logo Singlifezesty customer logo Acornszesty customer logo Phoenix Sunszesty customer logo Wattpadzesty customer logo Corner Shopzesty customer logo Bjs

Enter your details to connect with a Content Expert

First Name

Last Name

Email

Phone (optional)

Company

Please tell us about your project (optional)

G2 MOMENTUM LEADER

zesty customer logo zesty customer logo zesty customer logo zesty customer logo