Summary: Ziflow allows you to review websites using two different methods:
Snapshot: Ziflow creates a snapshot of the web page so that your reviewers can comment on the proof like they would on a document. Feature available on all Ziflow editions
Live website: Your reviewers can comment and interact with the live website content as if viewing it in their browser. Feature available on all Ziflow editions.
This article outlines how described functionality appears and operates in the old layout. If you are using Dashboard 2.0, please refer to the corresponding article in the Help Center.
Where is the feature applied? On the proof creation screen. Simply enter a website URL, or multiple URLs, into the "Review a website" box. You can choose to take a snapshot or view the live content.
Reviewing a static website proof
Once a website proof has been created, you can enter the Ziflow Viewer to begin the review and approval process. You'll notice that a website snapshot looks exactly the same as any standard image proof.
Reviewing a live website proof
You'll notice a small bar at the top of the Ziflow Viewer when proofing live website captures.
Website resolution - allows you to display the proof in other screen resolutions to see how the website looks on other devices. There are over a dozen different options to choose from.
Change orientation - rotates website orientation according to the selected resolution. This feature works only if you switch resolution from your default browser resolution to some custom value selected from the website resolution picker.
Interactive/panning mode - allows you to switch between interactive and panning modes. When the arrow button is blue, then the interactive mode is on. It means that you can browse the proof as a normal website (play videos, interact with all the content). If you draw a markup or use any other proofing tool, the proof will remain in the panning mode, and browsing won’t be possible (the interactive mode button will be greyed out). You can start browsing the proof once the interactive mode is switched back on.
Refresh - reloads the whole proof to the initial HTTPS address.
Home - click the button to redirect you to the home page address.
Why is my live website proof not loading correctly in the viewer?
The Ziflow proof viewer is hosted securely (HTTPS). To support "non-secure" sites (HTTP), we load them using our own proxy servers since the browsers don't allow mixed content (secure and non-secure) to be loaded at the same time.
If the non-secure site contains any direct links to other non-secure content, the browser will load this directly, and it will not be proxied via our servers. The browser will block the content in this case, and your site may not load correctly.
There are two ways to fix this:
Host the website securely (HTTPS)
Change links in the web page from absolute to relative paths. You can either do this by editing your original website, or you can let Ziflow attempt to do this automatically when loading the website:
Go to Manage Account > Proofing Settings > Proof Viewer > Other options and activate Live websites: URL rewriting.
Proofing pages protected with reCaptcha
If you want to proof page, which is protected with reCaptcha, please:
Open the Settings of your v3 API Account
At the Domains option, only put in the proof-proxy.ziflow.net domain
Proofing staging or password-protected websites
If you're in need of reviewing staging or password-protected websites, we allow passing login credentials inside the proof URL so reviewers don't need to sign in when they open the proof.
Please note that this bypass method supports websites that are behind some basic auth methods, but if the website is protected by some more advanced auth (session-based authentication, token-based authentication, or OAuth/OpenID Connect protocols), it may be blocked from viewing within the Ziflow Viewer.
While it's technically possible to pass credentials in the query string of a URL to bypass a login screen, it's an extremely insecure practice and should never be used in a production environment. This method poses significant security risks, as the credentials are transmitted in plaintext and can be easily intercepted by malicious actors.
Additionally, web applications typically do not authenticate users solely based on the presence of credentials in the query string. They employ more secure authentication mechanisms such as session-based authentication, token-based authentication, or OAuth/OpenID Connect protocols.
Using the query string for passing credentials can lead to:
Security Vulnerabilities: Transmitting sensitive information, such as usernames and passwords, in plaintext exposes them to interception by attackers.
Risk of Exposure: URLs with credentials can be logged by web servers, proxies, and browsers, potentially exposing them to unauthorized access.
Violation of Best Practices: Storing credentials in the query string violates security best practices and industry standards.
There are two formats for passing the credentials along with the URL:
https://mywebsite.com/?bypass=(username)-(password) (this solution has to be implemented on the website to be working properly)
Simply replace mywebsite.com with your staging website address and supersede both username and password with your website credentials.
Now, create a live website proof with a generated URL and open the proof to see if the authorization worked.
Our recommended way to proof staging websites is to configure them only to be accessible from specific IP addresses (including Ziflow). This guarantees the website's security and prevents anyone outside the specified IPs from accessing it.
After allowing HTTPS and WSS traffic through the following IPs, your website should display inside the Ziflow Viewer without any issues.
3.217.63.90
3.218.57.116
52.0.97.84
54.196.210.150
34.231.210.90
3.212.239.47
3.228.239.233
34.239.40.84
52.40.115.54
3.219.6.198
3.215.49.22
34.198.41.161
52.87.96.158